先日GoでInstagramぶっこ抜きというものを作った時、リクエスト方法について少し悩んだ。
個人開発で大規模なものじゃないから、リソースについてそんなにシビアにならなくてもいいのだが、一度考えてみた。
全体の動き
サーバーにajaxでリクエスト(POST)を投げて、レスポンスを画面に描画するという動き。
POSTするのはInstagramのURLで、サーバーでは受け取ったURLをcurlしてごにょっとしてレスポンスとして返す。
レスポンスがあるたびに画面描画しているので、細かく投げれば投げるほど進捗状況が見やすい。
リクエスト方法
考えると言っても大体下記の3つぐらいしか思いつかなかった。
- 1URL1リクエスト
- URLをある程度まとめてリクエスト(分割)
- URLを1つにまとめてリクエスト
1URL1リクエスト
メリット
- 進捗が正確
- 1リクエストがコケても他に影響しない
デメリット
- リクエスト数が多い(最大)
別に小規模だったらこれでもいいかなあとは思う。リクエスト数が多いといってもたかがしれているだろうし。
ただLamdaとかで動かす場合、リクエスト数で課金が決まってしまうので得策ではない気もする。
URLをある程度まとめてリクエスト(分割)
メリット
- 進捗がある程度正確。まとまりごとに結果が表示される
- 1リクエストがコケても他にあまり影響しない
- リクエストがまあまあ少ない
デメリット
- 特に無い
まあ、無難ですわな。
URLを1つにまとめてリクエスト
メリット
- リクエスト数が少ない(最小)
デメリット
- 進捗が正確ではない。一気にドバっと結果が表示される
- 1リクエストがコケたら全部に影響する
1リクエストが重くなりレスポンスまでが長くなるし、コケたら終わりなのでこれはナシ。
結論
なんやかんや中間の「分割して送信する」がベストなんだろう。
中間を取るというのは自分の性格上あまり好きではないが、システム的には適している気がする。 実際はサーバー側でも最大処理数(同時接続数的なやつ)を設定したりするだろう。
