消費RESTサービス：クライアントまたはサーバー
現在使用しているテクノロジーとフレームワークを現在決定している新しいプロジェクトに取り組んでいます。アプリケーションは最終的にクロスプラットフォームになります。したがって、サーバー側では、REST Java Springで記述されたAPIを使用します。
現在、フロントエンドWebアプリケーションに使用するテクノロジを決定しています。
オプションは次のとおりです。
フロントエンドのJavaScriptフレームワークを使用します（おそらくember jsを使用します）。ページは純粋にJavaScriptでレンダリングされ、すべてのRESTリクエストは内部から送信されますエンバー
PHPサーバーフレームワーク（Laravel）を使用します。すべてのREST呼び出しはLaravel内から行われます。サーバーサイドページのレンダリング
私の質問：どのアプローチが最善ですか？なぜ？オプション2を実行する場合（laravelを使用して要求を行う）、Laravelを使用するのはやりすぎです）ビューを生成し、REST api's？（すべてのロジックはREST API）からのものです）を呼び出します。オプション1で問題になるのは、レンダリングが初期ロード時間に影響を与えるクライアント側で実行されるアプリケーションは、ローエンドのハードウェアを使用するユーザーによっても広く使用されます。
他の提案やより良いオプションがある場合は、お知らせください！
よくあることですが、状況によって異なります
純粋なJSフレームワーク
- 多くの処理をクライアントにプッシュします。つまり、クライアントアプリケーションのウェブサーバーは、キャッシュ可能な静的ファイルのみを提供します。
- クライアントはその処理を処理できなければならず、ある程度の計算能力が必要です。
- クライアントは、フロントエンドフレームワークが使用するすべてのJS機能を完全にサポートする必要があり、フレームワークが古いブラウザーに提供するサポートにいくらか縛られています。フレームワークの最新バージョンが、クライアントが依拠している古い一部のIE=バージョンのサポートを終了することを決定した場合、それで立ち往生します。
- REST APIのエンドポイントは、問題となる可能性があるすべてのクライアントからアクセスできる必要があります
中間層があるということは
- 処理能力を単一のサーバーに配置します。これは制御可能なものであり、必要に応じてリソースを追加できます。クライアントにとってこれはより難しく、時には不可能です
- REST APIへの呼び出しを制御することができます。たとえば、データをキャッシュするため、毎回APIをヒットする必要はありません。
- REST APIのエンドポイントを公開する必要がないため、セキュリティをより詳細に制御できます
- レンダリングされたHTMLをより詳細に制御でき、フレームワークによって提供されるコンポーネントに関連付けられていません。最初にJSを使用してビューの一部を構築するコンポーネントを作成し、パフォーマンスが問題になったときに、サーバーから生成されたHTMLに置き換えることができます。
- サーバー側のプログラミング言語機能を備えたサーバーを実行および維持する必要がある
問題は、これらの問題のどれがあなたにとって重要で、どれが重要でないかです。ローエンドのハードウェアをサポートする必要がある場合は、JSフロントエンドフレームワークは使用しません。この方法でパフォーマンスを制御することは非常に難しく、実行できる最適化には非常に制限があります。
別の観点から [〜＃〜] jdt [〜＃〜] にポイントを追加したい。
理論的には、サーバーは1つですが、クライアントは多数あります。したがって、ビジネスロジックをサーバー側に配置した場合、すべてのクライアントでビジネスロジックをやり直す必要はありません。これがAPIの実際のポイントだからです。 Web、Android、iOSなどのAPIを使用しています。
ただし、一部の機能がクライアントごとに異なる場合は、クライアント側に配置します。