Backend for Frontend

マイクロサービス アーキテクチャでは、当社のシステムは、ユーザー サービス、注文サービス、製品サービスなど、多数の小規模で焦点を絞ったサービスに分割されます。 しかし、この情報をユーザーに表示する場合、デバイスごとにニーズは大きく異なります。高速デスクトップ コンピューター上の Web ブラウザーには、テーブル、サイドバー、グラフが満載のリッチなダッシュボードが必要です。低速のセルラー ネットワーク上のモバイル アプリでは、帯域幅とバッテリーを節約するために、シンプルで軽量なレイアウトが必要です。スマートウォッチ アプリには 1 行のテキストのみが必要な場合があります。 これらすべてのフロントエンドがまったく同じバックエンド API をクエリする場合、誰かが妥協する必要があります。モバイル アプリは大量の役に立たないデータをダウンロードすることを強いられるか、Web アプリは必要なものをすべて取得するために何十もの個別のネットワーク リクエストを行うことを強いられます。 これは、フロントエンド用バックエンド (BFF) パターン によって解決されるまさに問題です。このガイドでは、このパターンを簡単な言葉で説明し、現実世界の類似点を見て、それを標準の API ゲートウェイと比較し、実際のコード実装について説明します。 現実世界のたとえ: レストランのメニュー 3 つのまったく異なるタイプの食事を提供するレストランを想像してください。 食品評論家。詳細な成分リストを含む完全な 5 コースのテイスティング メニューを望んでいます。 忙しい通勤者で、電車の中で簡単に包装済みの軽食を食べたいと考えています。 子供は、スパイシーな食材を使わず、少量でシンプルなお子様の食事を望んでいます。 もしレストランに、3 つのオプションすべてを詳細に記載した 1 つのメニューしかなかったとしたら、それは圧倒されるでしょう。通勤者は5品コースのレシピを読むのに時間を無駄にし、子供の親は簡単な食事の選択肢を見つけるのに苦労するでしょう。 代わりに、レストランでは 3 つのカスタム メニュー (テイスティング メニュー、エクスプレス To-Go メニュー、キッズ メニュー) を印刷します。 各メニューは同じキッチン (マイクロサービス) から取得されますが、その顧客 (クライアント) に合わせて選択肢の形式とサイズが設定されます。 このシナリオでは: キッチンはマイクロサービス (ユーザー、カタログ、支払い) を表します。 カスタム メニューはあなたの BFF (Web BFF、Mobile BFF、Watch BFF) です。 ダイナーはフロントエンド (デスクトップ ブラウザ、モバイル アプリ、スマートウォッチ) です。 問題: 「万能」API マイクロサービスが最初に普及したとき、多くのチームは、すべてのフロントエンド クライアントを処理する単一の共有 API ゲートウェイを構築しました。