「BFFとAPIゲートウェイ」は、マイクロサービスアーキテクチャにおいて最も混同されやすい組み合わせの一つです。これら2つのパターンは、図で見ると似ています。どちらもサービスの前に位置し、クライアントのリクエストを受け取り、バックエンドに渡します。そのため、チームはこれらが競合する選択肢であるとみなし、どちらか一方を選んでしまい、結果として誤った責務を押し付けることになります。
しかし、これらは競合するものではありません。Backend for Frontend (BFF) とAPIゲートウェイは、それぞれ異なる問題を解決し、異なるチームによって管理され、多くの場合、同じシステム内で連携して動作します。BFFはゲートウェイの代わりではなく、その背後または隣に位置します。
このガイドでは、その境界線を明確にします。各パターンが実際に何であるか、どこが重複しているか、どちらか一方または両方を使用すべき時期、そしてそれらを混同することから生じる間違いについて学びます。全体を通して、APIコントラクトは不変です。リクエストがゲートウェイ、BFF、あるいはその両方を通過する場合でも、各レイヤーは設計、テスト、モック、ドキュメント化する必要があるAPIを公開します。
APIゲートウェイとは何か？
APIゲートウェイは、クライアントとバックエンドサービスの間にある集中型の入り口です。すべてのリクエストはゲートウェイを通過し、ゲートウェイは一貫した横断的関心事を適用してから、後続の呼び出しをルーティングします。
これらの関心事は、すべてのクライアントとすべてのサービスに対して共通です。
- ルーティング: 受信したパスを適切なアップストリームサービスに一致させます。
- 認証と認可: トークンを検証し、未承認の呼び出し元を拒否します。
- レート制限とスロットリング: バックエンドを過負荷や悪用から保護します。
- 可観測性: リクエストをログに記録し、メトリクスを出力し、サービス間の呼び出しをトレースします。
- TLS終端、キャッシング、リクエスト変換: インフラストラクチャ処理を一度に一箇所で扱います。
ゲートウェイの決定的な特徴は、それが汎用性があり、中央集権的に所有されていることです。プラットフォームチームまたはインフラストラクチャチームがこれを運用し、すべてのクライアントに平等にサービスを提供します。呼び出し元がモバイルアプリであろうと、ウェブSPAであろうと、パートナーインテグレーションであろうと関係なく、すべてのユーザーに同じポリシーを適用します。
このため、ゲートウェイは組織全体にわたるルールを置くのに最適な場所となります。すべてのリクエストを同じ方法で認証したり、すべてのAPIを一貫してレート制限したりしたい場合、各サービスがそのロジックを再実装することなく、ゲートウェイがそれを強制します。より広範なプラットフォームツールとの違いについては、API管理 vs APIゲートウェイを参照してください。
Backend for Frontend (BFF) とは何か？
Sam Newmanによって提唱されたBackend for Frontendは、その向きを変えます。すべてのクライアントにサービスを提供する1つの汎用バックエンドではなく、ユーザーエクスペリエンスごとに1つのバックエンドを構築します。ウェブアプリにはウェブBFFを、モバイルアプリにはモバイルBFFを用意します。各BFFは、正確に1つのフロントエンドに合わせて調整されます。このパターンは、多数のクライアントにサービスを提供する単一の共有バックエンドがモノリスと同じ種類のボトルネックになるというマイクロサービス作業から生まれました。
Newmanの経験則は「1つのエクスペリエンスに1つのBFF」です。大幅に異なるフロントエンドにはそれぞれ独自のBFFが割り当てられ、似たようなもの（同じチームによって保守されているiOSアプリとAndroidアプリ）は1つのBFFを共有できます。
ここでの決定的な特徴は、所有権と形状です。Newmanの言葉を借りれば、BFFは「特定のユーザーエクスペリエンスに密接に結合しており、通常、ユーザーインターフェースと同じチームによって保守されます」。フロントエンドチームがそのBFFを所有します。彼らは、個別のバックエンドチームがすべての変更を承認するのを待つことなく、クライアントとそのバックエンドを一緒に進化させます。
BFFは実際に何をするのでしょうか？1つのクライアントのためにデータを整形します。
- 集約: モバイル画面は5つのマイクロサービスからデータを必要とします。モバイルBFFはこれら5つすべてを呼び出し、結合された1つの応答を返すため、電話は5回ではなく1回の往復で済みます。
- トリミングと整形: モバイルクライアントは40個のフィールドのうち3つしか必要としません。BFFは帯域幅を節約するために残りを削除します。
- クライアント固有のフォーマット: デスクトップアプリは豊富な表示のために複数のページを一度に取得しますが、モバイルアプリは軽量に保つために1ページずつ取得します。各BFFはクライアントのパターンに合わせてサービスを提供します。
BFFは、個性を持つAPIアグリゲーターの一種です。ダウンストリームの呼び出しを構成しますが、中立的で共有されたレイヤーとしてではなく、常に1つの特定のフロントエンドのためにサービスを提供します。
BFFとAPIゲートウェイの重複する点
両方のパターンが表面的な動作を共有しているため、混同されるのは理解できます。どちらもクライアントリクエストを傍受します。どちらもバックエンドにルーティングできます。どちらも複数のサービスを呼び出し、結果を結合できます。どちらの図も、クライアントとサービスの間にある箱のように見えます。
重複は確かにありますが、それは表面的なものです。違いは意図と所有権にあります。
- APIゲートウェイは、ポリシーを一元化するために、すべてのクライアント向けに汎用的に集約およびルーティングします。
- BFFは、特定のフロントエンドの体験を最適化するために、そのフロントエンド向けに具体的に集約およびルーティングします。
Microsoft自身のガイダンスでは、どの職務がどこに属するかについて明確に述べています。監視、認可、レート制限といった横断的機能は、BFFから抽象化され、ゲートウェイ型パターンによって個別に処理されるべきです。BFFはクライアント固有のロジックのみを持つべきです。認証とスロットリングをBFFに組み込むと、ゲートウェイの半分を不完全に再構築したことになり、作成するすべてのBFFで同じことを繰り返すことになります。
したがって、実用的な境界線は次のとおりです。すべてのクライアントにとって同じ責務であれば、それはゲートウェイに属します。フロントエンドごとに異なる場合は、BFFに属します。
BFFとAPIゲートウェイの連携
実際のマイクロサービスシステムでは、一方を選ぶことはほとんどありません。両方を階層的に実行します。ゲートウェイがエッジに位置し、BFFはその背後に置かれます。
典型的なリクエストフローは次のようになります。
- モバイルクライアントは認証トークン付きでリクエストを送信します。
- APIゲートウェイはトークンを検証し、レート制限を適用し、可観測性のためにリクエストをログに記録した後、モバイルBFFにルーティングします。
- モバイルBFFはプロダクトサービス、インベントリサービス、価格サービスを呼び出し、結果を集約し、モバイル画面に必要なペイロードにトリミングして、1つの応答を返します。
- ゲートウェイは応答をクライアントにストリーミングします。
Microsoftのこのパターンのリファレンスアーキテクチャはまさにそれを実行します。API管理ゲートウェイが認可、監視、キャッシング、ルーティングを処理し、その後、サーバーレス関数として実行されているクライアント固有のBFFサービスに転送し、BFFサービスが基盤となるマイクロサービスを呼び出します。
各レイヤーは得意なことを行います。ゲートウェイは統一されなければならないポリシーを担当します。BFFは特定されなければならない形状を担当します。フロントエンドチームはゲートウェイの設定に触れることなくBFFに変更をデプロイでき、プラットフォームチームはBFFを再デプロイすることなくレート制限を強化できます。
このレイヤー構造は、ゲートウェイが他のインフラストラクチャを置き換えるのではなく、共存する方法に似ています。ゲートウェイはロードバランサーでも（APIゲートウェイ vs ロードバランサー）、サービスメッシュでもありません（サービスメッシュ vs APIゲートウェイ）。それぞれがリクエストパスの異なるレイヤーを処理し、BFFは単にさらに1つの異なるレイヤーに過ぎません。これはAPI主導型接続の背後にある原則と同じです。各レイヤーに明確な役割を与え、それだけを実行させます。
決定表: BFF vs APIゲートウェイ
| 質問 | APIゲートウェイ | BFF |
|---|---|---|
| 誰が所有するか？ | プラットフォーム / インフラストラクチャチーム | それを利用するフロントエンドチーム |
| 誰にサービスを提供する？ | すべてのクライアントに、一律に | 1つの特定のフロントエンドに |
| 主な役割 | 横断的関心事: 認証、レート制限、ルーティング、可観測性 | クライアント固有の集約とデータ整形 |
| いくつ実行するか？ | 通常1つ（エッジごとに） | 異なるユーザーエクスペリエンスごとに1つ |
| 結合 | 疎結合、クライアント非依存 | 密結合、設計上クライアント固有 |
| 変更頻度 | 安定、プラットフォーム管理 | 速い、フロントエンドのロードマップに追従 |
| 含まれるもの | すべてのクライアントで同一のもの | 1つのクライアントに固有のものすべて |
責務のルーティングに関する質問としてこれを読んでください。全員に共通するものはゲートウェイに入れます。フロントエンドごとに異なるものはBFFに入れます。もしある責務が両方に該当する場合（中央集権的な認証とクライアントごとのペイロード整形の両方を望む場合）、それはどちらか一方を選ぶのではなく、両方のレイヤーを実行すべきであるという合図です。
どちらを使用すべきか
APIゲートウェイは、 複数のサービスがあり、認証、レート制限、ルーティングを一貫して強制するための一箇所が必要な場合に使用します。ほとんどすべてのマイクロサービスシステムが恩恵を受けます。クライアントに公開されるサービスがいくつかある場合、他の何よりも先にゲートウェイが必要になります。
BFFは、 異なるクライアントが同じバックエンドから意味のある異なるニーズを持ち、共有の汎用APIがボトルネックになっている場合に使用します。Microsoftのガイダンスによると、一般的なきっかけは次のとおりです。
- 競合する複数のフロントエンドにサービスを提供するため、共有バックエンドの維持に多大な労力が必要となる。
- 複数のインターフェースに対応するために、汎用バックエンドをカスタマイズし続ける必要がある。
- モバイルとウェブが、データとパフォーマンスに関して本当に異なるニーズを持っている。
BFFをスキップすべきなのは、 すべてのインターフェースが同じまたは類似のリクエストを行う場合、あるいはバックエンドと対話するインターフェースが1つしかない場合です。BFFはネットワークホップ、デプロイするサービスの増加、そしてBFF間でのコード重複の可能性を追加します。単一の共有APIがすべてのクライアントにうまく機能する場合、BFFは不要なオーバーヘッドとなります。Microsoftは、フロントエンドごとのリゾルバーを持つGraphQLレイヤーも、クライアントが必要なフィールドを正確にリクエストできるため、別途BFFを必要としない場合があることに言及しています。
両方を使用するのは、 大規模なマイクロサービスを運用している場合です。エッジで統一されたポリシーを適用するためのゲートウェイと、その背後でクライアント固有のデータ整形を行うためのBFFsを使用します。これは、珍しい状態ではなく、一般的な最終形態です。
よくある間違い
- 認証とレート制限をBFFに置くこと。 これは最も主要な間違いです。横断的関心事はゲートウェイに属します。これらをBFF間で重複させると、乖離が生じます。モバイルBFFは1つのポリシーを、ウェブBFFは別のポリシーを強制し、セキュリティ態勢が意図せず一貫性を失います。
- BFFを第二のモノリスにしてしまうこと。 BFFは小さく、1つのエクスペリエンスに焦点を当てることを意図しています。チームが共有ビジネスロジックをBFFに詰め込むと、再び汎用バックエンドに成長し、このパターンが取り除くはずだったまさにそのボトルネックを再導入することになります。
- ゲートウェイをBFFとして使用すること。 一部のチームは、BFFを構築することを避けるために、クライアントごとのリクエスト変換ルールをゲートウェイ設定に直接追加します。これは小規模では機能しますが、ゲートウェイは中央集権的に所有されているため、フロントエンドチームはクライアント固有の調整ごとにプラットフォームチームにチケットを提出することになります。間違ったチームを結びつけてしまっています。
- クライアントが1つしか存在しないのにBFFを構築すること。 単一のウェブアプリしかなく、他にクライアントが登場する見込みがない場合、BFFは時期尚早です。共有APIを提供し、2番目の異なるクライアントが実際に登場したときにBFFを追加してください。
- コントラクトを忘れること。 すべてのBFFとすべてのゲートウェイルートはAPIを公開します。それぞれが他のAPIと同様に、定義されたコントラクト、テスト、ドキュメントを必要とします。これを怠ると、「薄い」BFFレイヤーは、所有チーム以外誰も統合できない未文書のブラックボックスとなってしまいます。これが重要である理由については、APIコントラクトとは何かを参照してください。
Apidogが適合する場所
リクエストがAPIゲートウェイ、BFF、あるいはその両方を通過する場合でも、各レイヤーはAPIコントラクトを公開します。Apidogは、これらのコントラクトを設計、テスト、モック、ドキュメント化するための場所です。ApidogはゲートウェイやBFFを構築、ホスト、または置き換えるものではありません。それらが公開するAPIサーフェスに対する単一のワークスペースを提供します。
具体的には：
- 設計: ビジュアルデザイナーでBFFの集約された応答やゲートウェイのルーティングされたエンドポイントをスキーマファーストでモデル化し、その後、フロントエンドとバックエンドの両チームがそれに基づいて構築できるようOpenAPIを生成します。
- モック: モバイルチームがBFFのダウンストリームサービスが存在する前に画面を開発できるように、BFFのスマートモックを立ち上げます。これは、並行したフロントエンドとバックエンドの作業を可能にするAPIファーストのワークフローです。
- テスト: 実際のクライアントがそうするように、ゲートウェイによって公開されたエンドポイントを叩く自動テストシナリオを構築し、認証、ステータスコード、および集約されたペイロードの形状を検証します。
- ドキュメント: 各BFFとゲートウェイルートのインタラクティブなドキュメントを公開し、利用するすべてのチームが実装を読まずにコントラクトを理解できるようにします。
選択するパターンはアーキテクチャの決定です。各レイヤーが公開するコントラクトは不変です。Apidogはこの不変の部分を処理するため、どのように連携させてもBFFとゲートウェイは設計、テスト、モック、ドキュメント化された状態を保ちます。
Apidogを無料で試して、バックエンドコードを一行も書く前にBFFとゲートウェイのコントラクトを設計およびモックしてください。
よくある質問
- BFFはAPIゲートウェイの一種ですか？ いいえ。両者がルーティングと集約の点で重複することはありますが、BFFはフロントエンドチームが所有し、1つのクライアントエクスペリエンスに合わせて調整される一方、APIゲートウェイは中央集権的に所有され、すべてのクライアントに一律にサービスを提供します。BFFは通常、ゲートウェイの背後に位置します。
- APIゲートウェイなしでBFFを使用できますか？ はい、できますが、大規模な場合は通常そうすべきではありません。ゲートウェイがないと、各BFFが認証やレート制限などの横断的関心事を再実装する必要があり、一貫性が失われます。ゲートウェイはそれらを一元化するため、各BFFはクライアント固有のデータ整形のみを扱います。
- いくつのBFFを持つべきですか？ Sam Newmanの「1つのエクスペリエンスに1つのBFF」という原則に従ってください。大幅に異なるフロントエンドごとに個別のBFFを構築します。iOSアプリとAndroidアプリのように、同じチームによって保守されている類似のクライアントは、1つのBFFを共有できます。
- BFFは私のAPIゲートウェイを置き換えますか？ いいえ。これらは補完的なレイヤーです。ゲートウェイはエッジで一律のポリシーを強制し、BFFはその背後で特定のクライアントのためにデータを整形します。ほとんどの実際のマイクロサービスシステムでは両方を実行します。
- BFFを構築すべきではないのはいつですか？ すべてのクライアントが類似のリクエストを行う場合、クライアントが1つしか存在しない場合、またはフロントエンドごとのリゾルバーを持つGraphQLレイヤーによってクライアントが必要なデータを正確に取得できる場合は、BFFをスキップしてください。
- 認証とレート制限はBFFとゲートウェイのどちらに属しますか？ ゲートウェイです。これらはすべてのクライアントで統一されるべき横断的関心事です。これらをBFFに置くと、すべてのBFFでロジックが重複し、ポリシーの乖離を招きます。