ビューまたはフロントエンドサーバーがRESTful APIレイヤーを呼び出すか

Question

新しいWebアプリケーションを構築する必要があり、APIレイヤーへの通信を管理する方法に関するアドバイスを探しています。私の目標は、フロントエンドとバックエンドのコードを完全に分離することです。ほとんどの場合と同様に、ビューを提供するフロントエンドサーバーを用意する予定ですが、バックエンドサーバーは私のAPIレイヤーを公開します。

APIからデータをプルする方法に少し戸惑っています。

ノードサーバーはAPIへのすべての呼び出しを処理し、そのデータをビューに提供する必要がありますか？
またはビューはAPIを直接呼び出すことができ、サーバーに管理を許可する必要がありますOAuth magic？

私は他の人がこれに取り組むために何をしたのか知りたいです。あなたの考えを教えてください。良い資料がありましたら、ぜひお聞かせください。

James · Accepted Answer

短い答え：

あなたの環境と目標について、シンプルで役立つ短い答えを出すのに十分な情報がありません。以下の私の長い答えを見てください。

長い答え：

これは答えるのが本当に難しい質問です。チームとプロジェクトには、システムに最適なアーキテクチャの決定につながる具体的なことがたくさんあります。うまく答えるためには、このWebアプリの目標と要件をより詳細にする必要があります。例えば：

APIは公開されますか、それともWebアプリでのみ使用されますか？つまり、ファイアウォールの背後にあり、Webアプリにのみアクセスできる内部サービスなどと考えるべきでしょうか？
このアプリにはどのくらいのトラフィックが予想されますか？（1,000ユーザー/月？10k？100k？1m？）
ページの読み込み速度はどれくらいですか？（つまり、アプリケーションは実際に反応する必要があるか、それに対して反応する必要がありますか？）
アプリの作成にはどのくらいの時間がかかりますか？
本当にOAuthが必要ですか？
あなたのチームには何人いますか？
「学習体験」から「ビジネスをサポートする」までのこのプロジェクトはどこにありますか？
「実用的、それを成し遂げる」から「完全に技術的に正確でなければならない」まで、このプロジェクトはどこにありますか？
このアプリは検索エンジンによってインデックスに登録されますか、それとも（認証メカニズムの背後で）ほとんど非公開になりますか？

「実用的」対「完全」の質問に対する私の意見は、より実用的なものにすることです。出荷されなければ、プロジェクトはあなたが学んだこと以外には関係ありません。

質問1、2、および3の回答は、システムがどれほど大きくて複雑である必要があるかを示しています。（大量のトラフィックが予想され、ページの読み込み時間がそれほど重要でない場合は、より多くのレイヤーとシステムが導入される可能性があります。キャッシュできるデータの領域がある場合、データの取得が遅い他の場所を相殺する可能性があります。）

認証とアカウント作成について。これは、本当に理解するのに時間がかかる驚くほど複雑なトピックです。自分のAPIに対してOAuth（仮定OAuth 2.0）と想定）、通常のパスワード認証、またはOAuth 3番目の認証に対して-party（facebook、googleなど）でも、システム内にユーザーアカウントを作成する方法が必要です。

OAuthの場合：OAuthの最も一般的な使用法は、サードパーティのシステム/サービスがユーザーの1人が所有するシステム内のデータにアクセスできるようにすることです。ただし、柔軟性はありますが、パスワードベースのログインを許可します。これは、ユーザーがシステムにアカウントを作成すると、「リソース所有者パスワード資格情報」付与タイプをOAuth 2.0で使用して認証できることを意味します。ユーザー。 full rfc をまだ確認していない場合は確認してください。

Webアプリケーションを設計する一般的な方法をいくつか示します（これは包括的ではなく、さまざまなバリエーションがあります）。

JavaScriptでフロントエンドフレームワークを使用して（エンバー、angularなど）と考えて）、すべてのビューを管理し、サーバー上のAPIから適切なデータを要求します。このAPIは、パブリックAPIまたはそのアプリでのみ使用されるAPI。
必要なサービスごとに内部サービス（API）を備えた外部向けWebアプリレイヤーがある多層サーバーアーキテクチャを作成します。 Webアプリレイヤーにはビューがあり、内部サービスからすべてのモデルデータを取得します。すべての内部サービスはファイアウォールの背後にあります。たとえば、 TripAdvisor がそれを行う方法を参照してください。
パブリックAPIを提供し、サーバー上のビューから生成された個々のHTMLページを提供する標準のサーバーベースのWebアプリを作成します。（つまり、WebアプリはパブリックAPIを使用せず、すべての内部データベースおよびサービスに直接アクセスします。）
サードパーティが使用するパブリックAPIを提供し、Webアプリのみが使用するセミプライベートAPIを作成します。これは＃1の特定のバリエーションです。

私は＃1、＃3、または＃4に従います。-ユーザーが10万人未満であることがわかっているシステムを構築している場合-10万人を超えるユーザーをサポートする必要があり、システムの機能の数が少ない（つまり、非常に複雑な製品）

（＃2と（＃1、＃3または＃4））（操作順序を明確にするために括弧）の組み合わせに従います：-他の多くのシステムで多くのバックエンド処理が行われている場合-私が10万人を超えるユーザーをサポートする必要があり、非常に大きな機能セット/処理するさまざまな種類のデータが多数ある

公開されていて、検索エンジンによってインデックスが作成される製品がある場合、私はしない＃1も＃4もしません。

私のチームは私にとって非常に重要です。彼らの好み、経験、学びたいという願望は、私がアーキテクチャ的に＃1 /＃4と＃3の間で選択するものに影響します。