Webのリクエスト方法についてやんわりと考えてみる

先日GoでInstagramぶっこ抜きというものを作った時、リクエスト方法について少し悩んだ。
個人開発で大規模なものじゃないから、リソースについてそんなにシビアにならなくてもいいのだが、一度考えてみた。

rasukarusan.github.io

全体の動き

f:id:rasukarusan:20190717205355p:plain

サーバーにajaxでリクエスト(POST)を投げて、レスポンスを画面に描画するという動き。
POSTするのはInstagramのURLで、サーバーでは受け取ったURLをcurlしてごにょっとしてレスポンスとして返す。
レスポンスがあるたびに画面描画しているので、細かく投げれば投げるほど進捗状況が見やすい。

リクエスト方法

考えると言っても大体下記の3つぐらいしか思いつかなかった。

  • 1URL1リクエスト
  • URLをある程度まとめてリクエスト(分割)
  • URLを1つにまとめてリクエスト

1URL1リクエスト

f:id:rasukarusan:20190717204933p:plain

  • メリット

    • 進捗が正確
    • 1リクエストがコケても他に影響しない
  • デメリット

    • リクエスト数が多い(最大)

別に小規模だったらこれでもいいかなあとは思う。リクエスト数が多いといってもたかがしれているだろうし。
ただLamdaとかで動かす場合、リクエスト数で課金が決まってしまうので得策ではない気もする。

URLをある程度まとめてリクエスト(分割)

f:id:rasukarusan:20190717205024p:plain

  • メリット

    • 進捗がある程度正確。まとまりごとに結果が表示される
    • 1リクエストがコケても他にあまり影響しない
    • リクエストがまあまあ少ない
  • デメリット

    • 特に無い

まあ、無難ですわな。

URLを1つにまとめてリクエスト

f:id:rasukarusan:20190717205043p:plain

  • メリット

    • リクエスト数が少ない(最小)
  • デメリット

    • 進捗が正確ではない。一気にドバっと結果が表示される
    • 1リクエストがコケたら全部に影響する

1リクエストが重くなりレスポンスまでが長くなるし、コケたら終わりなのでこれはナシ。

結論

なんやかんや中間の「分割して送信する」がベストなんだろう。
中間を取るというのは自分の性格上あまり好きではないが、システム的には適している気がする。 実際はサーバー側でも最大処理数(同時接続数的なやつ)を設定したりするだろう。