ウェブサイトのライブアップデート - 1秒あたり1 ajaxは悪い練習ですか？

Question

私は各ユーザーが複数のの注文を持つことができるウェブサイトを持っています。各注文にはステータスがあります。バックグラウンドプロセスは、必要に応じて各注文のステータスを更新し続けます。私は、彼の注文の状況をリアルタイムでユーザーに知らせたい。このように、私は、特定のユーザーのすべての注文を返すAPIエンドポイントを開発しました。 クライアント側では、注文を表示するReactコンポーネントを開発しました。その後、すべての注文とステータスを取得するためにAJAXリクエストがAPIに対して実行され、Reactは必要に応じて自動更新されます。

ユーザーのすべての注文を悪い習慣にするには、毎秒1 AJAXコールを行っていますか？私ができる他の戦略は何ですか？

Answer 1

はい、そうです。あなたはこれを達成するためにSocketを使うことができます。見てみるSocket.IO

編集：私の指摘は、AJAXを使用して、そのために設計された機能で実行できるタスクをシミュレートする理由は何ですか？ソケットはちょうどこのようなことをするように作られています。

たとえば、ユーザーがインターネット接続を失ったとします。 Socket.IOではこれを非常にうまく処理できます。しかし、私はAJAXでそれが簡単になるとは思わない。

スケーラビリティについて考えてみると、Socket.IOはどのような転送でもパフォーマンスが向上するように設計されています。接続が可能であることに基づいて正常に機能を低下させる方法はすばらしく、サーバーができるだけ過負荷になると同時に、可能な限り多くのユーザー層に到達することを意味します。

AJAXはトリックを行いますが、それは最高のデザインではありません。

Answer 2

この質問に対する回答はすべて1つではありません。

まずはチャットアプリではありませんが、1秒未満の遅延でもユーザーエクスペリエンスが大幅に変更されることはありません。

だから、技術的な理由で私たちを残し、それは本当に多くの要因に依存します：あなたは（全体の負荷を）持っている

どのように多くのユーザー、どのように多くの同時ユーザーが行う、あなたが使用しているインフラ、彼らの注文を待っていますビルドするには他に重要なことがありますか、楽しいものをコーディングするために時間を費やしたいだけですか？

ユーザー数が少ない場合は、1秒に1回クエリを実行するのに間違いはありません。簡単でメンテナンスオーバーヘッドが少なく、既にコード化されていると言いました。

ステータスを待っている同時ユーザーが何十人もいる場合は、WebSocketを使用するのが最善の方法です。

インフラストラクチャに関しては、あまりにも多くのWebソケットが高価です（一部のクラウドホスティングではソケット数に制限があります）ので、そのルートを使用したい場合は注意してください。