Webアプリケーションに個別のAPIサーバーとUIサーバーを使用する利点

Question

職場では、現在2年近く開発されている大規模な内部アプリケーションがあります。私は最近プロジェクトに参加したばかりで、アーキテクチャの一部が少し困惑しているので、ここにいる誰かが建築家に同じ質問をする前にアドバイスを提供してくれることを望んでいます（そのため、彼らと十分な情報を得た議論ができます）。

以下が少し長い場合は申し訳ありませんが、質問する前に、システムが何であるかについての良い絵を描こうと思います:)

システムのセットアップ方法は、1つのメインWebアプリケーション（asp.net、AngularJS）があり、ほとんどが他のさまざまなサービスからのデータを集約するだけです。つまり、基本的にはAngularJSアプリケーションのホストです。クライアント側をブートストラップする文字通り1つのMVCコントローラーがあり、他のすべてのコントローラーはWebAPIコントローラーです。
クライアント側からの呼び出しは、これらのコントローラーによって処理されます。コントローラーは常に、Webアプリケーションをホストするだけのボックスに展開されます。現在、このようなボックスが4つあります。
ただし、コールは最終的にさらに別のWebAPIアプリケーションのセットにルーティングされます（通常、これらはセキュリティ、顧客データ、製品データなどのビジネスエリアごとです）。これらのWebAPIはすべて一緒に専用のボックスにデプロイされます。これらのボックスも4つあります。
1つの例外を除いて、これらのWebAPIは、組織の他のどの部分でも使用されていません。
最後に、これらのWebAPIは、「バックエンド」サービスに対してさらに別の呼び出しを行います。これは、通常、さまざまなERPシステムおよびデータストアの上に配置されたレガシーasmxまたはwcfサービスです。コントロール）。
アプリケーションのビジネスロジックのほとんどは、レガシーデータの変換、集約、ビジネスルールの実行など、通常のタイプのWebApiに含まれています。

私が混乱しているのは、WebApplicationとそれを提供するWebAPIの間にそのような分離があることで得られる可能性のある利点です。他の誰もそれらを使用していないため、スケーラビリティの利点はありません（APIサーバーの負荷の増加はWebサーバーの負荷の増加を意味するため、別の4つのAPIボックスを追加して負荷の増加を処理しても意味がありません-したがって、WebサーバーとAPIサーバーの比率は1：1である必要があります）

また、Browser => HTTP => WebApp => HTTP => WebAPI => HTTP => Backend servicesを追加で呼び出さなければならないというメリットはまったくありません。（WebAppとWebAPI間のHTTP呼び出しが私の問題です）
そのため、現在Pushを使用して、現在のWebAPIを個別のソリューションから、WebApplicationソリューション内の個別のプロジェクトに移動し、その間に単純なプロジェクト参照を配置し、単一の展開モデルを使用できるようにしています。つまり、最終的にはクラスライブラリになるだけです。
展開に関しては、これは、4 + 4ではなく8つの「フルスタック」Webボックスがあることを意味します。

新しいアプローチの利点は、

WebアプリケーションとWebAPIサーバー間のシリアライゼーション/デシリアライゼーションのサイクルが1つ少ないため、パフォーマンスが向上します。
WebアプリケーションサーバーとWebApiサーバーの送信境界と受信境界のDTOとマッパーに関して、削除可能な（つまり、保守/テストの必要がない）大量のコード。
意味のある自動化された統合テストを作成する機能が向上しました。これは、バックエンドサービスを単純にモックし、中間層のHTTPジャンプに関する混乱を回避できるためです。

だから問題は、私は間違っているのですか？ WebApplicationボックスとWebAPIボックスを分離したことによる基本的な「魔法」を見逃しましたか？

私はいくつかのN層アーキテクチャー資料を調査しましたが、私たちの状況に具体的なメリットをもたらすものを見つけることができないようです（スケーラビリティは私の知る限り問題ではなく、これは内部アプリなので、 WebAPIアプリケーションに関するセキュリティは問題ではありません。）

また、システムを自分の提案したセットアップに再編成した場合、メリットに関して何が失われますか？

gbjbaanb · Accepted Answer

1つの理由はセキュリティですハハ！---（いつ）ハッカーがフロントエンドWebサーバーにアクセスした場合、ハッカーはアクセスできるすべてのものにアクセスできます。中間層をWebサーバーに配置した場合、彼はそれが持っているすべてのもの、つまりDBにアクセスでき、次に知っていることは、DBで「select * from users」を実行してオフラインから削除することです。パスワードクラッキング。

もう1つの理由は、スケーリングです。ページが構築および分解され、XMLが処理されるWeb層と、DBからWeb層にデータを取得する効率的な方法であることが多い中間層よりも多くのリソースを必要とします。 Webサーバー上にある（またはキャッシュされている）すべての静的データを転送することは言うまでもありません。 Webサーバーを追加するのは簡単です。1を過ぎると、Web層とロジック層の間には1：1の比率はありません。これまで8：1でした（そしてロジックの間は4：1の比率です）。層およびDB）。ただし、層が何を行うか、およびそれらの層でどの程度のキャッシングが行われるかによって異なります。

ウェブサイトはスケーリングに合わせて構築されているため、シングルユーザーのパフォーマンスをあまり気にしません。より多くのユーザーにサービスを提供できることを意味する場合、追加の呼び出しが少し遅くなることは問題ではありません。

これらのレイヤーを使用するのが良いもう1つの理由は、APIが開発され（スタンドアロンであるので簡単にテストされ）、開発にUIが開発され、UIがそれを使用するように開発されるためです。私はこれを行う場所で働いていました-異なるチームが異なるレイヤーを開発し、他の層について心配する必要がなかったので本当に迅速に変更をクランクアウトできる各層のスペシャリストがいたのでうまくいきました-つまり、UIジャバスクリプト開発者他の誰かが開発した新しいWebサービスを使用するだけで、サイトに新しいセクションを追加できます。

Stefan Woehrer · Answer

ここで正解はありません。このアーキテクチャの目的について同僚に尋ねましたか？

私の説明を理解すると、アーキテクチャの「WebAPI」は、一種の自作ミドルウェアとして機能します。これで、ミドルウェアの使用にどのような利点があるかを調査できます。基本的に、WebAPIインターフェイスが同じである限り、バックオフィスシステムを変更した場合でも、Webアプリケーションを採用する必要はありません。

さらに進むには、顧客データベース（バックエンドサービス）があり、そのデータベースと通信する5つのWebアプリがあるとします。顧客のデータベースシステムを新しいシステム（別のベンダーのシステムなど、Webサービスインターフェイスに影響を与えられないようなもの）に置き換える場合、5つすべてのWebアプリケーションの通信層を変更する必要がある可能性があります。 WebAPIを介して通信する場合は、WebAPIの通信層を変更するだけです。

基本的に、レイヤーアーキテクチャは現在、PatternとAnti-Patternの両方と見なされています。（参照： Lasagna-Code ）今後数年間でこれをさらに拡張する予定のないシステムが1つしかない場合は、これをアンチパターンと見なしたいと思います。しかし、私は正確な状況/状況を知らないので、これは非現実的なタフ裁判官になるでしょう:)