JavaScript - Web サイトのフロントエンドとバックエンドの分離の問題、API の作成

ウェブサイトのフロントエンドとバックエンドの分離の問題:
例えば、ホームページは複数のモジュールで構成されており、各モジュールには独自の API インターフェースがあります
フロントエンドのスタッフは私にデータを返すように頼みました。すぐにインターフェイスを結合する必要があります
これでいいですか?それとも、複数のリクエストを通じて個別にデータを取得する方が良いでしょうか

返信内容:

ウェブサイトのフロントエンドとバックエンドの分離の問題:
例えば、ホームページは複数のモジュールで構成されており、各モジュールには独自の API インターフェースがあります
フロントエンドのスタッフは私にデータを返すように頼みました。すぐにインターフェイスを結合する必要があります
これでいいですか?それとも、複数のリクエストを通じて個別にデータを取得する方が良いでしょうか

もっと深刻な解決策を教えてください。ただし、あなたの質問には答えられないかもしれません。

ビッグフロントエンドの概念に従い、途中にNodeレイヤーを追加すると、フロントエンドはサーバーサイドレンダリングを完了し、バックエンドはAPIを統合することができます。これはフロントエンドによって維持され、バックエンドは必要ありません。自分で実行してください。 :)

リソース消費量が同じ場合、またはリソース消費量が比較的小さい場合、1 つのインターフェースで処理できる場合は 2 つのインターフェースを作成しないでください

Node、go、およびその他の同時実行性の高い API。 RESTful API の観点からは、一度にすべてを送信しないことをお勧めします。これは、フロントエンドの変化に応じてバックエンドも常に変化していることを意味し、分離やモジュール化には適していません。フロントエンドはキャッシュを作成し、redux やデータ キャッシュなどの対話を削減できます。毎回データを取得するためにバックエンドにアクセスする必要はありません。データを一度与えたとしても、すべてを取得するためにバックエンドにアクセスするのをやめることはできません。多数のデータを取得した後、最初にキャッシュを使用し、一定時間経過後、またはユーザーが更新をクリックしたときにサーバーにアクセスしてデータを取得できます。

結局のところ、HTTP リクエストは少ないほど良いのですが、コードを数行書くだけです

。

役割が異なれば、問題に対する視点も異なります。
フロントエンドの観点から見ると、すべてのリクエストが返されるため、http リクエストが減り、パフォーマンスが向上し、フロントエンドが送信するリクエストが少なくなる可能性があります。
バックエンドの観点から見ると、インターフェースはモジュールで書かれており、明確かつ簡潔です。

私自身バックエンド担当者です。私の一般的な意見は、[適切だと思います。開発は難しくなく、影響はありません]。返されたデータでは、モジュールも区別できます。別のキーに追加し、後で追加することもできます。モジュールの削除も非常に簡単です。

それぞれに役割があり、正しいか間違っているかを議論する必要はありません。どのような状況にも絶対に適した解決策はありません。

もちろん、主張することもできます。

数十ページのページ分割されたデータなど、大量のデータが返される場合は、必ずページングに基づいてデータを取得する必要があります。

返されるデータが少なく、大量のデータが返されてもパフォーマンスに影響がない (つまり、影響が無視できる) 場合は、一度返すことをお勧めします。これにより、ワークロードが大幅に軽減される可能性があります。フロントエンドのリクエストと同時に、リクエストデータの時間もそれほど頻繁ではないため、パフォーマンスにも優れています。

HTTP 2.0の使い方を知りませんか?

HTTP 2.0 の複数のリクエストは、一度送信されれば、それに値します。

また、バックグラウンドが RESTful である場合、結合されたインターフェイスはロジックを破壊し、非常に有害です。フロントエンドが RESTful を認識していない場合は、それを有効にするだけです。

それでは、新しいインターフェースを開いて、必要に応じてさまざまなモジュールのデータを組み合わせるだけです。とにかく、さまざまなモジュールがカプセル化されているので、それらを呼び出すだけです。このインターフェイスもこの目的のために特別に使用されます。これらを混合しないでください。