プッシュはデータを保持するか、レシーバーにAPI呼び出しをトリガーさせる必要がありますか？
WebSocketを使用すると、データが変更されたことをクライアントに通知する必要がある場合、次の2つのアプローチがあります。
- サーバーは、プッシュ内でデータ変更を直接プッシュします。
- または、サーバーがデータをプッシュせず、クライアントが受信すると、API呼び出しをトリガーして更新されたデータを取得します。
どちらを使用しますか？その場合は？
私の場合、サーバーはHTTPエンドポイントを介してデータを提供する前にかなり多くの計算を行うので（つまり、not「このデータベーステーブルをシリアル化する」だけです）、最初のアプローチを選択すると思います。そのため、これらの計算をサーバー側だけでなくクライアント側でも行う必要はありません。
ただし、先に進む前に、これについてご意見をお聞かせいただければ幸いです。
次の質問が選択に影響を与える可能性があります。
- サーバーが結果を計算するのにどれくらいの時間が必要ですか？
- 一意のリクエストの結果ですか、それとも複数のリクエスターにブロードキャストされますか？
- プッシュされるデータ（ペイロード）の大きさはどれくらいですか？
- クライアントは、プッシュされたすべての結果に常に関心がありますか？
- 一部の結果が失われる可能性がありますか、それともデータを常に配信する必要がありますか？
- クライアントが接続を失ったり、接続品質の問題が発生したりする可能性はありますか？
これらの問題に基づいて、次の場合にデータプッシュを選択できます。
- 接続は信頼できます
- またはデータが大きすぎない場合
- またはクライアントが常に結果に興味を持っている場合
- または結果を頻繁に更新する必要がある場合
- または結果が可能な限りリアルタイムで必要な場合
プッシュ通知 または Server-Sent-Events に興味があるかもしれません）（SSE）他のすべての場合、およびたとえば以下に対処するために：
- 再接続（SSEを使用）および閉じたクライアントアプリケーション
- 大量のデータセットを送信する場合のネットワーク品質の問題により、送信を延期することがより快適な代替手段になります（または、海外で携帯電話を使用する場合の莫大なローミングコストを考慮に入れてください...）
- 廃止された結果を無視する
- サーバー側の制約で全二重が許可されていない場合、または http を経由する必要がある場合
ただし、SSEはブラウザ ではWebSocketほどサポートされていないため 、後者の方が簡単に選択できることに注意してください。