メインコンテンツまでスキップ

🧩 API Gateway / BFF（Backend for Frontend）

✅ このスタイルの概要​

複数のバックエンドサービスをまとめて公開する「入口（Gateway）」と、
クライアント種類ごとに最適化されたバックエンドを用意する「BFF」の構造スタイル。

✅ 解決しようとした問題​

マイクロサービスや複数クライアント（Web / モバイル / 外部パートナー）が登場すると：

  • クライアントが多数のサービスを直接呼び出すと複雑になる
  • 認証・認可・レートリミット・ロギングなど共通処理が重複
  • Web とモバイルで必要なデータ形が違い、同じ API では使い勝手が悪い

API Gateway / BFF はこれに対して：

  • 共通の入口で横断的な関心事を処理し
  • クライアント種類ごとに最適化された Facade を用意する

という構造で応える。

✅ 基本思想・ルール​

● API Gateway​

  • 外部からのすべてのリクエストの入口
  • 主な役割：
    • 認証・認可
    • レートリミット
    • ロギング・トレーシング
    • ルーティング（どのサービスに送るか）
    • プロトコル変換（外部は REST、内部は gRPC など）

● BFF（Backend for Frontend）​

  • 特定のクライアント（Web, iOS, Android 等）に特化したバックエンド
  • 役割：
    • クライアントごとに適切なデータ形に変換
    • 複数サービス呼び出しのオーケストレーション
    • クライアント特有のユースケースを集約

構成例：

  • Internet → API Gateway → Web BFF → 各種バックエンドサービス
  • Internet → API Gateway → Mobile BFF → 各種バックエンドサービス

✅ 得意なアプリケーション​

  • Web / モバイル / 外部パートナー API を同時に提供する SaaS
  • マイクロサービスが多く、クライアントが直接すべてを知るべきではないシステム
  • クライアントごとに画面設計・UX が大きく異なるプロダクト

❌ 不向きなケース​

  • シンプルなモノリシックアプリ（API が 1 つのバックエンドで完結）
  • クライアントが 1 種類しかなく、複雑な集約ロジックも不要な場合

過剰に BFF を増やすと：

  • 境界が増えすぎて変更コストが上がる
  • 同じようなロジックが複数 BFF に重複する

といった問題も起こるため、分割粒度に注意が必要である。

✅ 歴史（系譜・親スタイル）​

  • API Gateway 自体は SOA 時代から存在（ESB ＋ Gateway 等）
  • スマートフォンの普及とともに BFF の考え方が生まれた
  • Microservices, REST/gRPC/GraphQL の普及とともに標準的な構成要素になった

✅ 関連スタイル​

  • REST / gRPC / GraphQL：Gateway/BFF が表側で提供する API スタイル
  • Service Mesh：サービス間通信の内部実装を担うレイヤー（Gateway より内側）
  • Event-driven / Saga：Gateway/BFF からトリガーされる非同期フローの構成要素

✅ 代表的なフレームワーク​

API Gateway / BFF は製品としても OSS としても多くの選択肢がある。

  • AWS API Gateway / Azure API Management / GCP API Gateway
    マネージドな API Gateway サービス。認証・レート制限・ルーティングなどを提供。

  • Kong / Tyk / KrakenD / NGINX
    OSS / 商用の API Gateway 製品。プラグインによる拡張が可能。

  • Spring Cloud Gateway
    Spring エコシステム向けの API Gateway 実装。

  • Node.js / Express / NestJS 製 BFF
    Web / モバイルクライアント向けに特化した BFF を実装する際によく使われる。

  • Next.js（App Router / Route Handlers）
    Web フロントエンドと BFF 的な API を同一プロジェクト内で構成しやすい。

✅ このスタイルを支えるデザインパターン​

API Gateway / BFF はクライアントから見た“入り口”として、複数のパターンの組み合わせで成立する。

  • Facade
    複数バックエンドサービスを 1 つの API として見せる外観。

  • Adapter
    クライアントが扱いやすい形にデータやインターフェースを変換する。

  • Proxy
    認証・認可・レートリミット・キャッシュなど、リクエストの前後で制御を挟む。

  • Mediator
    複数サービスからのレスポンスを統合し、1 回のレスポンスにまとめる役割。

  • Strategy
    クライアント種類ごとのルーティングやレスポンス構造を切り替える場合に用いられる。

✅ まとめ​

API Gateway / BFF は、

  • 外部公開の入り口
  • クライアント特化のオーケストレーション層

として、モダンな Web / モバイルサービスではほぼ標準と言える構造スタイルである。

特に、
「どこまでを共通 Gateway に寄せ、どこからを BFF に分割するか」 が設計上の重要な判断ポイントになる。