API GatewayとBFFの類似点と相違点の比較
この文章は機械翻訳によって提供されています。原文は英語であり、OpenAIによって翻訳されました。
API Gatewayは、システム内のリソースにアクセスしようとするすべてのクライアントのエントリーポイントです。一方、Backend For Frontend（BFF）は、通常、複数のフロントエンドに対応する複数のBFFがある特定のフロントエンドに合わせて作成されます。ただし、それぞれのアプローチの理由をよりよく理解するために、その違いを考慮する価値があります。
API Gatewayとは？
API Gatewayは、すべてのクライアントがシステム内のリソースにアクセスしようとする際に通過するフィルターです。Redhat.comによれば、次のように説明されています。
「APIゲートウェイは、リバースプロキシとして機能し、すべてのアプリケーションプログラミングインターフェース（API）呼び出しを受け入れ、それらを満たすために必要なさまざまなサービスを集約し、適切な結果を返します。」
BFFとAPI Gatewayの違いは？
BFFは実際にはAPI Gatewayの一種です。実際、両者は同じ機能を果たしますが、主な違いは範囲、つまりどれだけのクライアントと対話するかです。BFFは特定のクライアントに合わせて作成されるため、通常はアプリケーションのフロントエンドビューに対応します。一方、API Gatewayは、ほとんどの（またはすべての）クライアントがデータにアクセスするための単一のゲートウェイとして機能します。
類似点
両方のアーキテクチャパターンは、基本的には同じ目標を達成するために使用されます。つまり、システムのバックエンドマイクロサービスをフロントエンドクライアントから切り離すことです。これにより、異なるプロトコルを持つクライアントとサービスが互いに対話する際に、同じ結果を得るためにコードを重複させる必要がなくなります。
API Gatewayでは、各クライアントはシステム内のさまざまなマイクロサービスの代わりにAPI Gatewayの場所のみを知る必要があります。API Gatewayは、認証やさまざまなマイクロサービスリソースのバンドルなどの機能を処理できます。BFFも同様のことを行いますが、より細かいレベルで行います。
相違点
前述のように、主な違いはどれだけのクライアントに対応するかです。標準のAPI Gatewayは、システムと対話するすべてのクライアントのリクエストを処理しますが、BFFは特定のクライアントのみを処理します。以下は、2つの異なるフロントエンドを持つアプリの例です。
- デスクトップブラウザのWebクライアント
- ネイティブモバイルクライアント（iOSまたはAndroid）
これらのフロントエンドごとに、それぞれの要件に合わせたゲートウェイが提供され、それぞれのニーズに合ったエンドポイントがカスタムで提供される場合、それぞれのゲートウェイはBFFと見なされます。
標準のAPI Gatewayを使用するべきか、それともBFFを使用するべきか？
どちらのアプローチにもトレードオフがあります。一般的にはBFFパターンが理想的ですが、より細かいカスタマイズが必要なため、メンテナンスがより複雑になります。標準のAPI Gatewayも、複数のフロントエンドでより効率的に機能するように最適化することができ、その振る舞いを正確にエミュレートすることもできます（一部制約があります）。
この問題は、アプリケーションがどれだけのクライアントと対話する必要があるか、アプリケーションのスケール、およびビジネスがこのアーキテクチャをカスタマイズするために割り当てるリソースなど、いくつかの重要な要素に帰結します。
多くのクライアントを持つ複雑なアプリケーション
- GraphQLとREST APIがJSONを提供するなど、異なるプロトコルをサポートする必要がある場合。
- 各クライアントに対して異なるニーズを持つ個別のチームが作業している場合。
- マイクロサービスの複雑なシステムがあり、クライアントに提供する前にゲートウェイでバンドル/集約する必要がある場合。
上記の場合、適切なBFFアーキテクチャを構築するために必要な時間とリソースを投資する価値があります。これにより、特定のフロントエンドに責任を持つ各チームが、他のチームの作業について心配することなく、独自のAPIニーズを管理できるようになります。各フロントエンドに専用のBFFがあることで、フロントエンド開発者が効果的に作業するために必要なデータリソースにアクセスできることも保証されます（バックエンドチームへの変更リクエストを頻繁に行う必要がなくなります）。
または、
1つまたは数少ないクライアントを持つシンプルなアプリケーション
- 単一のプロトコルで動作する場合。
- 単一のチームによって管理される場合。
- すべてのユーザーに対して単一の認証方法がある場合。
- 単一のゲートウェイで処理できる比較的シンプルなマイクロサービスのシステム。
この場合、アプリケーションのすべてのAPIニーズは、問題なく単一のAPI Gatewayで処理できる可能性があります。複数のBFFゲートウェイを構築して管理することは過剰であり、フロントエンドチームは必要なデータにアクセスできます。効率的な方法ではないかもしれませんが、問題はありません。
KurocoはAPI管理を考慮したヘッドレスCMSです
Kurocoは、エンタープライズチームが簡単にAPIエンドポイントを設定およびカスタマイズできる機能豊富なヘッドレスCMSです。私たちは、BFFパターンと同様の動作をするように簡単にカスタマイズできる単一のAPIゲートウェイを提供しています。これにより、バックエンドアーキテクチャを複雑に変更したり、高価な再構築を行う必要なく、エンタープライズのデータに簡単にアクセスできます。
Kurocoは、バックエンドとフロントエンドの関心事を切り離したいと考えている企業にとって、最適なソリューションです。当社のソリューションがお客様のビジネスにどのように役立つかについて詳しく知りたい場合は、お問い合わせいただくか、お気軽にご連絡ください。