ページ上のREST API呼び出しが多すぎますか？

8

高度にモジュール化された小さなコンポーネントを使用して設計されたWebアプリ（この場合はAngularJSディレクティブを使用しますが、WebComponents、ReactJSコンポーネント、またはその他のテクノロジと同じくらい簡単にできます）。多くの場合、コンポーネントには、初期化時またはユーザーの操作時に非同期REST API呼び出しがあります。この設計により、ページごとに多くのAPI呼び出し（20以上の場合もあります）が発生しています。このデザインに問題はありますか？シングルトンとして機能するより大きなクライアント側サービスにAPI呼び出しを圧縮することを提案している人もいます。したがって、ページがそのデータの一部しか使用しない場合でも、10回のAPI呼び出しは1回に削減される可能性があります。赤い旗、またはこのデザインの問題はありますか？どちらを優先すべきですか？

rest api async

— ライアン・ラングトン
ソース

これの多くは、発生するレイテンシとユーザーへの影響に依存していると思いますか（彼らはそれに気づきますか）？

— Niall

これらは非同期呼び出しであり、ほとんどが一度に発生します（ページの初期化）。したがって、ユーザーには、すべてのデータが読み込まれるまで、わずかにグレー表示された画面と読み込みバーしか表示されません。ユーザーエクスペリエンスは良いと思います。私の唯一の懸念はサーバー呼び出しの量です、それは問題です（APIの制限など？）。従来のアプリでは、ページごとにサーバーを1回呼び出していました。

— Ryan Langton

1

手元にある制限については知りません。それはトレードオフのように聞こえます。設計とメンテナンスとレイテンシとなど。私は少ないほうがいいですが、データはすべて呼び出しに関連しています（つまり、必要なデータがAPI呼び出しに関連しない場合は、別の呼び出しにします）。認めますが、これは1の6、他の6だと思います。

— Niall

HTTP 2にサーバーをアップグレードを検討

— CodesInChaos

2

ブラウザは同時リクエストの総数を制限します

/programming/561046

だから、はい、このデザインには問題があります。ただし、受け入れられた応答は、単一の接続を使用するが、サーバーと通信するために多くのメッセージタイプを使用するWebソケット実装に移動することです

— ユアン
ソース

1

制限はブラウザごとなので、これは問題のようには見えません。したがって、6つを超える呼び出しがある場合、他の呼び出しはキューに入れられます。Webソケット接続の方が効率的であることに同意しましたが、必要かどうかはわかりません。

— ライアンラングトン

あなたが私が推測するそれらの呼び出しをどのように使用しているかに依存します。主な問題は、クライアント側のコードがますます複雑になるにつれて、JavaScriptの制限に直面し始めることです。例えば。マウスオーバーでテキストの色を変更するように設計された言語で接続プーリングソケットクライアントをコーディングする

— Ewan

「そうです、このデザインには問題があります」-それはあまりにも包括的な声明のようです。この設計を正常に実装する方法はたくさんあります。

— リチャード

2

この設計により、ページごとに多くのAPI呼び出し（20以上の場合もあります）が発生しています。このデザインに問題はありますか？

あってはいけません。各リクエストが小さく非同期であることは、1つの大きなリクエストが完了するのを待たずにすべてをブロックするのではなく、Webアプリを大幅に高速化できることを意味します。

JavaScriptが適切に非同期であり、他のリクエストが待機している間に何かを実行できることを確認してください。すべてをフェッチする1つの大規模なリクエストよりもはるかに優れたアプリになります。

すべてのブラウザが多数のURLのロードをタンデムで処理するように設計された後、一般的な標準のWebページでさえ、画像、CSS、JavaScript、iFrameなどへのリクエストが数百とまではいかなくても数十になる可能性があります。

— コーマック・マルホール
ソース

1

各ネットワーク要求のサイズを忘れないでください。一般に、各リクエストが2 KBのデータのみを返す場合、その少量のデータに対してネットワークリクエストは高価になります。

ネットワーク要求が最大400KBになる場合は、2つに分割します。しかし、一般的には、1つのネットワーク要求に対して十分なデータがないことが問題であることがよくあります。

— dman
ソース

0

ここでの考慮事項：

パフォーマンス

許容できるパフォーマンスが得られている場合は、あまり気にする必要はありません。HTTP2を実行することができれば、パフォーマンスが向上するはずです。^[1]。

設計

他のデザインと同様に、多数の小さなリクエストを実行する必要があるか、少数の大きなリクエストを実行する必要があるかについて、厳密なルールはありません。考慮すべき事項：

通話の多くは相互依存していますか？異なる呼び出し間に複雑な依存関係がある場合、メンテナンスが困難になる可能性があります。この場合、関連する応答データをバッチ処理することは理にかなっています。
異なるコンポーネントが同じデータの多くを共有していますか？これが当てはまる場合は、共有呼び出しを実行し、コンポーネントが共有データにアクセスできるようにする中心点を設けることができます。
個別の呼び出しを行う小さなコンポーネントのメンテナンスの負担に注意してください。管理が困難になり、変更が必要になる場合があります。将来の架空のニーズに基づいて設計を変更すると、将来発生する問題を正確に予測する必要があるため、設計ミスを引き起こす可能性があります。現在、問題なく機能している場合は、変更する必要もありません。

1：「HTTP / 2は完全に多重化されており、一度に1つの要求/接続のみを受け入れるHTTP1.xとは対照的に、複数のファイルと要求を同時に転送できます。HTTP/ 2は、同じ接続を使用して異なる転送を行いますファイルとリクエストにより、クライアントとサーバー間で転送する必要があるすべてのファイルに対して新しい接続を開くという重い操作を回避できます。」- https://css-tricks.com/http2-real-world-performance-test-analysis/

— Tjaart
ソース