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

職場では、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でなければなりません）

• また、ブラウザ=> HTTP => WebApp => HTTP => WebAPI => HTTP =>バックエンドサービスを追加のHTTP呼び出しを行う必要があるという利点もまったくありません。（WebAppとWebAPI間のHTTP呼び出しが私の問題です）

• そのため、現在は、現在のWebAPIを個別のソリューションから、WebApplicationソリューション内の個別のプロジェクトに移動し、間に単純なプロジェクト参照と単一の展開モデルを配置することを検討しています。したがって、最終的にはクラスライブラリになります。

• 展開に関しては、これは4 + 4ではなく8つの「フルスタック」Webボックスがあることを意味します。

新しいアプローチのメリットは次のとおりです。

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

だから質問は：私は間違っていますか？WebApplicationボックスとWebAPIボックスを分離したという基本的な「魔法」を見逃していませんか？

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

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

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

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

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

これらのレイヤーを持つことが良いもう一つの理由は、APIが開発され（そしてスタンドアロンなので簡単にテストされる）、それを消費するために開発されたUIで開発の規律を強めることです。私はこれを行った場所で働いていました-異なるチームが異なるレイヤーを開発し、各層の専門家がいて、他の層を心配する必要がないため、本当に迅速に変更を行うことができました-すなわち、UI javscript dev他の人が開発した新しいWebサービスを使用するだけで、サイトに新しいセクションを追加できます。

ここには正しい/間違った答えはないと思います。このアーキテクチャの目的について同僚に尋ねましたか？

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

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

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