遅いAPI応答に依存するUI更新の処理方法
私が何人かの友人と取り組んでいるサイドプロジェクトは、現在、多くの理由で遅く、速度を改善するために変更できないAPIインターフェイスを扱っています。 5秒から25秒の範囲でかかるAPI応答のことです。古いソフトウェアですが、統合する必要があります。そのAPI応答が返された後、データベースに書き込み、UIを更新して更新された状態を反映します。
問題は、ユーザーがこのAPIを使用するアクションを1日に最大100回実行する必要があることです。応答が返されるまでUIをブロックすることは明らかに非効率的ですが、最初のAPIが応答する前にAPIへの2番目の非同期呼び出しを処理するオーバーヘッドも維持および書き込みが困難です。私が考えることができるよりも良い解決策についてのアイデアはありますか？
これはすべてMEANスタックに書き込んでいることに注意してください。
応答が返される前に完全なUIをブロックする必要はありません。 UIの一部を無効にするだけで、最初のAPI呼び出しが完全に処理される前に（もちろん非同期操作で）別のAPI呼び出しを実行できます。
それが可能かどうかは、UI、アプリケーションの機能、およびそれらがAPI呼び出しにどのように関連付けられているかに大きく依存します。
最初のAPIが応答する前にAPIへの2番目の非同期呼び出しを処理するオーバーヘッドも維持および書き込みが難しい
なぜそうなのか、そしてあなたが言うように本当に難しい場合は、再考することもできます。私はあなたのUIがすでにイベントドリブンであると思います。したがって、さまざまなソースからのあらゆる種類のイベントを任意の順序で処理する必要があります。 「応答イベント」はこれと同じであってはなりません。確認する必要があるのは、関連する以前の要求イベントによって引き起こされたグローバルな状態に依存しない応答イベントだけです。代わりに、最新の以前の「リクエスト」イベントが次の着信応答に属するものであるという事実に依存せず、応答イベントから取得する情報パッケージ全体が自己完結型である必要があります。これが可能かどうかは、APIとそれがシステムにどのように統合されているかによって異なります。
応答が来る前かどうかにかかわらず、ユーザーが複数のAPI要求を開始できるようにすることとは関係なく、開いている要求についてユーザーに知らせる視覚的なフィードバックがUIにあるはずです。リクエストが届くまでUIのAPI関連パーツを無効にすることは、おそらくユーザーにこのフィードバックを提供する最も簡単な形式です。次のAPIリクエストをブロックせずにAPIリクエストを許可したい場合でも、ユーザーはリクエストを開始するために「彼が押したボタン」（たとえば）が正常にヒットされたことを知る必要があります。 UIは、開いているリクエストのリスト、増加したカウンター、進行状況バーなどを表示する可能性があるため、「ボタン」を数回押して反応を強制することはありません。