web-dev-qa-db-ja.com

バックエンドとフロントエンドのWebアプリケーションを完全に分離して、それらが（JSON）REST APIと通信できるようにすることは、通常の設計ですか？

新しいビジネスWebアプリケーションを作成していて、次のことを実現したいと考えています。

  • それぞれの分野から最高のテクノロジーを使用してください。確実なORMを備えた信頼性の高いバックエンドフレームワークが必要です。そして、フロントエンドアプリケーションに最新のHTMLおよびJavascript機能を使用した、最も高度なSPA（シングルページアプリケーション）フレームワークが欲しい
  • さまざまなタイプのアプリケーションから使用できるように、バックエンドエンティティとビジネスサービスを公開します。 Webアプリケーション、モバイル（Android）、およびその他のタイプ（スマートデバイスなど）

したがって、両方の要件を満たすために、私はバックエンドアプリケーションとフロントエンドアプリケーションでアプリケーションを完全に分離し、REST API（JSON）を使用してそれらの間の通信を整理します）これは健全なアプローチですか？

多くのWebアプリケーションテクノロジーにはビューレイヤーが統合されており、サーバーサイドアプリケーションがビューの生成をある程度制御し、ビューからの応答を部分的に処理するため（たとえば、ビューレイヤーを含むSpringMVC、PHP Yii with view layer、Java JSF/Faceletsは、コンポーネントの状態をサーバーに完全に保存します。）より強力なカップリングを提案し、開発時間の短縮と標準的な道のりを約束する周辺のテクノロジーなので、広く使われていない方法でテクノロジーを使い始めるときは注意が必要です。

私が理解しているように、完全に分離されたSPAフロントエンドは通常、サードパーティのAPIを使用する必要性から生じます。しかしバックエンドとフロントエンドの両方が1つの会社によって開発されている場合、このような分離サウンド設計はありますか？

私が現在選択しているテクノロジーは、Java/Springバックエンドとフロントエンド用のAngular2/Web Components/Polymerです。しかし、この質問は一般的な設計に関するものであり、具体的な技術の選択に関するものではないため、この質問には関係ありません。

designrestapifront-endbackend
21
TomR

バックエンドとフロントエンドのWebアプリケーションを完全に分離して、それらが（JSON）REST APIと通信できるようにすることは、通常の設計ですか？

はい、それは正常です。しかし、そのような分離が必要であり、この設定をアプリケーション全体に強制しない場合にのみ、それは正常です

SPAには、いくつかの問題があります。ここに私の心に浮かんでいるほんのいくつかはここにあります：

  • ほとんどがJavaScriptです。アプリケーションのセクションに1つのエラーがあると、そのJavascriptエラーが原因で、アプリケーションの他のセクションが機能しなくなる可能性があります。サーバー（SpringMVC、PHPなど）から提供されるページでは、新しいセクションをリロードします。
  • [〜＃〜] cors [〜＃〜] 。必ずしも必須ではありませんが、多くの場合、バックエンドはフロントエンドとは異なるドメイン名にあります。したがって、ブラウザーのセキュリティ問題に対処する必要があります。
  • [〜＃〜] seo [〜＃〜] 。これが必要ですか？あなたのサイトは公開されていますか？ GoogleはJavascriptを理解し、サイトを理解しようとすることができますが、基本的にはボットを制御して最高のものを望みます。コントロールを取り戻すと、 PhantomJS のような他のツールに頼らざるを得なくなる場合があります。
  • 個別のフロントエンドアプリケーションとは、個別のプロジェクト、デプロイメントパイプライン、追加のツールなどを意味します。
  • すべてのコードがクライアント上にある場合、セキュリティは難しくなります。

もちろん、SPAにもメリットがあります。

  • フロントエンドでユーザーと完全に対話し、必要に応じてサーバーからのみデータをロードします。応答性とユーザーエクスペリエンスが向上しました。
  • アプリケーションによっては、クライアントで実行される一部の処理により、サーバーでの計算が不要になります。
  • バックエンドとフロントエンドを進化させる際の柔軟性が向上します（個別に実行できます）。
  • バックエンドが本質的にAPIである場合、ネイティブのAndroid/iPhoneアプリケーションのように、その前に他のクライアントを置くことができます。
  • フロントエンドの開発者は、サーバーアプリケーションをマシンで実行する必要なく、分離することでCSS/HTMLを簡単に作成できます。

つまり、両方のアプローチ（SPAとサーバーページ）には長所と短所があるということです。 時間をかけて両方のオプションを調査し、状況に基づいて選択します。

14
Bogdan

あなたの質問への答えは簡単です。はい。あなたが提案するのはsoundアプローチです。しかし、あなたが尋ねたいと思うのは、それがbetterアプローチであるかどうかであり、残念ながら、私たちの誰もあなたのためにそれに答えることはできません。関係する要素は多すぎる面に及んでいるため、組織と製品要件の両方についてすべてを明かさないと、本当の結論を出すことができません。とにかく、あなたは何をすべきかをすでに知っていると思います。

1
samazi

警告付きの正常。

フロントエンドのjavascriptフレームワークは、実行できることが制限されています。複数のアプリケーションで使用するために未加工のAPIを作成する場合、通常、その特定のアプリケーションで機能するビューモデルへの未加工のAPI呼び出しをサーバー側で処理する必要があります。

したがって、「通常の」アーキテクチャは次のようになります。

database
business logic services (dll)
api exposing business logic
server side website exposing viewmodels and functionality via json rest endpoints
client side javascript implementing ui

Webアプリケーションが1つしかない場合は、「API公開ビジネスロジック」レイヤーを切り取り、サーバー側のWebコードでビジネスロジックを直接呼び出すだけで済みます。

ビジネスロジックを独自のライブラリに分離したため、UIロジックから切り離されているため、いつでもサービスレイヤーを追加できます。

同様に、apiサービスはサーバー側のコードによって呼び出されるため、http通信に制限はありません。 （これは今ではほとんど普遍的ですが）

さらに、JavaScriptがサービスを提供するホストと同じホストを呼び出すことで、corsをいじくり回す必要がなくなります。

0
Ewan