これはトラブルシューティングの質問ではなく、業界標準の質問です。
私は、アーキテクチャの標準に取り組み、実装する必要がある岐路に立っています。これらの標準の 1 つに、クライアント アプリケーション (AngularJS ベースのため、複数のビューで永続的な単一ページ) とサード パーティの情報源との間の通信経路が含まれます。
私には、サードパーティのライブラリとデータに対するすべてのリクエストをバックエンド経由でルーティングし、CURL.
このように、サーバーはクライアントと外界との間のゲートウェイとして機能します (携帯電話のタワー ルーターと携帯電話の関係によく似ています)。
業界標準がこれについて何と言っているか、そして潜在的な落とし穴について興味があります。私には、長期的にはより多くの秩序、組織、およびセキュリティが作成されるように思えます.
外部の視点が必要なので、これに関するあなたの考えを教えてください。
私は業界標準を認識していないため、これが重要かどうかはよくわかりませんが、あなたが本当に求めているのは一般的な外部の視点であると解釈します. だからここに行きます：
私の短い答えは、あなたが正しい道を進んでいると思うということです。
クライアントが常にサーバーにリクエストを送信するという点でデータパスをシンプルに保つため、よりクリーンだと思います-したがって、基本的に、クライアントと他のすべてのものとの間の結合が非常に疎になります(サーバー上のコントローラーへの接続を除く)。必要なIMOでさえ）。後でデータ ソースを変更しますか? クライアントは影響を受けません (もちろん形式が異なる場合を除きます)。また、将来、何らかの理由で生データを DB に保存したいという自分自身をイメージできると便利です。接続しているサービスとデータで何をしたいかによっては、独自のサーバーを経由するとセキュリティ上の利点があります (サードパーティのサービスに対する認証に秘密鍵を使用する必要がある場合など)。 MasterCard が提供するような API を使用する)。
ただし、余分なリクエストと DNS ルックアップが発生することに加えて、サーバーの処理が増え、必要なメモリが少し増えるため、パフォーマンスが低下します。繰り返しになりますが、キャッシングを制御できるため、場合によってはサービスをもう少し堅牢にすることができます。
パフォーマンスが最優先でない限り、私はあなたが考えていたルートに行きます. サーバーでルーティングが正確にどのように行われるかは別の問題であり、いくつかのテストが必要になる場合があります。ポップアップする可能性のあるエラーをエレガントに処理できる方法を使用するようにしてください:)