以前javascriptで作成したものを修正した。
成果物
表示結果
CSSなしのブラウザで表示した結果。
前回まで
GitHubリポジトリ一覧ページの基礎ができた - やってみる
今回
前回までは最新の100件までしか表示できていなかったことに気づいた。今回は全件取得するよう改良した。
原因
100件しか取得できなかった原因はpagenationというGitHub APIの仕様である。
1リクエストあたり最大で100件分しか取得できない。全件取得するためには全件÷100
回リクエストが必要である。その際、URL引数にpage=2
のようにページ数を指定して取得する。
pagenationについては以下の資料を参照。
課題
sleep
- サーバ負荷対策のため1リクエストあたり最低2秒は待機したい
sleep関数があるかと思ったが存在しないらしい。思いのほか面倒くさそう。
エラー処理
- エラー処理が未実装
HTTPヘッダを得るためにsuccess()
,error()
をやめてthen()
を使った。そのため、エラー処理が未実装。
問題
前回と共通で、GitHub APIのリクエスト上限問題がある。リポジトリ数が増えるとpagenationの兼ね合いでリクエスト上限や応答時間の問題が深刻化する。
リクエスト上限
認証せずAPIを使用しているため、リクエスト上限は60回/1時間
(IP毎)である。
表示できる回数(件数)が少ない
Pagenationのため100件ごとに1回消費する。6000リポジトリあったとしたら、それを1時間に1回表示するだけでリクエスト上限に到達してしまう。
サーバ負荷が大きい
6000リポジトリあったとしたら、60回ものリクエストを要する。現実的でない。いずれ根本的な見直しが必要になる。
応答時間が長い
サーバ負荷対策のため1リクエストあたり2秒間の待機をしたい。そうすると応答時間が120秒間になる(6000リポジトリの場合)。とても実用的な時間ではない。最悪でも2秒後には応答してほしい。
AJAXで非同期に順次更新する工夫が考えられるが、最初にリポジトリ総数を表示したいので不都合。2秒ごとに100件ずつ増えていく様子を見ると「結局あと何件なんだよ!何秒後に結果が出るんだよ!すぐ出せよ!」とイライラしそう。
2017/02/10時点では約120リポジトリなので2回リクエストを必要としている。待機の実装もしていない。当分は問題にならないだろうが、いずれ対策を考えたい。
閲覧者のリクエスト上限を消費する
IP毎に60回/時なので、閲覧者のリクエスト上限を消費することになる。
これはいかがなものか。閲覧者様のリクエスト上限を無断で奪うことにならないか。せっかく見てくださった方のGitHubライフが害されないか。閲覧者様に対する裏切りや騙し討ちではないか。
かといって、私一人の認証で行うとすぐにリクエスト上限に達してしまう可能性がある。閲覧者が少ないならいいが、増えるとその分の負担を一人分の上限で補わねばならなくなる。それなら閲覧者ごとに分散してもらったほうがリクエスト上限が遠のく。
実際は大して問題にはならないかもしれないが、行儀の悪さを感じる。リクエスト上限を消費しないほうが良いに決まっている。
所感
本当はプログラミング言語とByteサイズの集計も表示したいのだが、この仕組みであるかぎり不可能か。もしくは実装方法を根本から見直すことになる。