思考過程をたどれるようになっている資料なので、読み物としてとても面白い。現実の問題を解決してるなー。
機能の価値とシステムリソースという現実の問題をデザインで上手く解決していく過程が説明されてて、とても良い資料。
めちゃくちゃ読み応えがある。単純なデバウンスじゃない。
700並列リクエストとかいう地獄をDebounceで解決は草。Redis使った実装が天才的すぎるｗ
おもしろ！
いまいち何が課題なのか分からなかった。全部終わったよでいいと思うけどなんでそれができない？
前提がよくわからなかった。同じテスト依頼が短時間に何回も来るから、全部は実行せず、最後のだけ実行したいということ？どういう条件でサマライズしていいのだろう？全部実行して問題ないならqueueでいけるはず。
内容は面白かったけど、なんか、TCPの再送バックオフを再発明している気がした。領域違うから最初からそうは思いつかないだろうけど、プロトコル屋さんならv2時点でバックオフ機構を入れれたかもね
バージョンを重ねるまでの過程が面白い / 並列でのデータ受け取り自体は問題ではなくて受け取ったデータの集計のタイミングを制御したい課題だろうからキューでは解決しない
やりがいしかなさそう
なぜThrottleではなくDebounceだったのか？ 700並列リクエストと戦うサーバーサイド実装のすべて
思考過程をたどれるようになっている資料なので、読み物としてとても面白い。現実の問題を解決してるなー。
機能の価値とシステムリソースという現実の問題をデザインで上手く解決していく過程が説明されてて、とても良い資料。
めちゃくちゃ読み応えがある。単純なデバウンスじゃない。
700並列リクエストとかいう地獄をDebounceで解決は草。Redis使った実装が天才的すぎるｗ
おもしろ！
いまいち何が課題なのか分からなかった。全部終わったよでいいと思うけどなんでそれができない？
前提がよくわからなかった。同じテスト依頼が短時間に何回も来るから、全部は実行せず、最後のだけ実行したいということ？どういう条件でサマライズしていいのだろう？全部実行して問題ないならqueueでいけるはず。
内容は面白かったけど、なんか、TCPの再送バックオフを再発明している気がした。領域違うから最初からそうは思いつかないだろうけど、プロトコル屋さんならv2時点でバックオフ機構を入れれたかもね
バージョンを重ねるまでの過程が面白い / 並列でのデータ受け取り自体は問題ではなくて受け取ったデータの集計のタイミングを制御したい課題だろうからキューでは解決しない
やりがいしかなさそう