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

私は新しいビジネスWebアプリケーションを作成しています。

• それぞれの領域から最高の技術を使用します。堅牢なORMを備えた信頼性の高いバックエンドフレームワークが必要です。そして、フロントエンドアプリケーションの最新のHTMLおよびJavascript機能を使用した、最も高度なSPA（単一ページアプリケーション）フレームワークが必要です。
• さまざまなタイプのアプリケーション（たとえば、Webアプリケーション、モバイル（Android）、および場合によっては他のタイプ（スマートデバイスなど））から使用するバックエンドエンティティとビジネスサービスを公開します。

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

多くのWebアプリケーションテクノロジーには、サーバーサイドアプリケーションがビューの生成を多少制御し、ビューからの応答を部分的に処理するビューレイヤーが統合されているため、このような分離は明白な設計ソリューションではありません（たとえば、ビューレイヤーを持つSpringMVC、ビューを持つPHP Yii Java JSF / Faceletsは、サーバー上のコンポーネントの状態を完全に保存します）。そのため、より強力な結合を提案し、開発時間の短縮とより標準的な道のりを約束する多くの技術があります。だから-広く使われていない方法で技術を使い始めるとき、私は注意しなければなりません。

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

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

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

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

SPAには、それに関連するいくつかの問題があります。ここに私の頭に浮かぶいくつかをご紹介します。

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

もちろん、SPAの利点もあります。

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

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

あなたの質問への答えは簡単です。はい。あなたが提案するのは、健全なアプローチです。しかし、その後、あなたが尋ねたいと思うのは、それがより良いアプローチであるかどうかであり、残念ながら、私たちはあなたのためにそれに答えることができません。関係する要因は多すぎるため、組織と製品の要件の両方を明かさなければ、真の結論を出すことはできません。とにかくあなたはすでに何をすべきか知っていると思います。

警告付きの通常。

フロントエンド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をいじる必要がないことを意味します。