サッカーアプリは、試合当日が始まるまで完璧に動作していた
サッカーアプリの開発は、最初は簡単そうに思えました。
試合データを取得し、チームを表示し、スコアを表示し、数秒ごとに更新するように計画しました。テスト中はうまくいきました。2つのタブといくつかのサンプル試合を使用しましたが、すべて順調に見えました。
しかし、最初の混雑する試合日がやってきました。
何百人ものユーザーが一斉にアプリを開きました。リクエストが重なり、スコアが逆戻りしているように見えるものもありました。アプリは、訪問者一人ひとりに対して、同じデータを個別に取得していました。
ライブアプリとは、単にAPIに接続されたウェブサイトではないということを学びました。それは「データ同期システム」なのです。
私が犯した間違いと、その解決策は以下の通りです：
クライアントサイドのみのポーリングを避ける 最初のバージョンでは、すべてのブラウザが5秒ごとにデータをリクエストしていました。 ユーザー1人 = 1分間に12リクエスト。 1,000ユーザー = 1分間に12,000リクエスト。 ほとんどのリクエストが、全く同じデータを求めていました。
サーバーサイドのリクエストを使用する APIコールをサーバー側に移動しました。これにより、以下を制御できるようになります： • API認証情報 • キャッシング • レート制限 • エラーハンドリング • レスポンスのフォーマット
クライアントサイドのコードにキーを絶対に含めないでください。キーが盗まれた場合、安全ではなく、コストも高くつきます。
マッピングレイヤーを作成する APIの生データをコンポーネントに直接渡すのをやめました。プロバイダーがフィールド名を変更すると、UIが壊れてしまうからです。現在は、まずプロバイダーのデータを独自の内部フォーマットにマッピングしています。これにより、UIの安定性が保たれます。
速度向上のためにServer Componentsを使用する ローディング画面を表示する代わりに、サーバー上で初期の試合データをロードします。ユーザーはすぐにコンテンツを見ることができます。
スマートなポーリングを実装する ライブ中の試合がない場合、アプリは更新すべきではありません。試合終了時にポーリングを停止するチェックを追加しました。これにより、サーバーリソースを大幅に節約できます。
レースコンディションを修正する 時として、リクエストBがリクエストAよりも先に返ってくることがあります。これにより、スコアが逆戻りしているように見えてしまいます。私はAbortControllerを使用して、新しいリクエストを開始する前に古いリクエストをキャンセルするようにしています。
エラーを適切に処理する 更新に失敗しても、空の画面を表示しないでください。最後に成功したデータを表示したままにします。15秒前のスコアの方が、スコアが表示されないよりはマシです。
デモはデータを表示するだけで済みますが、実際の製品はキャッシング、セキュリティ、および状態（ステート）を管理する必要があります。
ライブアプリを構築したことはありますか？実際のユーザーが訪れたとき、何が壊れましたか？
Source: https://dev.to/mihailove123/my-football-app-worked-perfectly-until-matchday-started-3i59