マイクロサービス化が進むにつれ、
クライアントが必要なデータを取得するために 多数のマイクロサービスへ直接リクエストする 必要が出てきた。
このような背景から、以下の課題が顕在化する。
マイクロサービス化によって生じる課題
- クライアントが接続するマイクロサービスの増加により、
各マイクロサービスの API 仕様を意識した実装が必要になり、フロントエンドが複雑化する - 複数 API へのアクセスが必要なため、
クライアント・サーバー間の通信量が増加する - バックエンドのリプレイスや設計変更により
API の粒度やレスポンス構造が変わると、各クライアントが修正を強いられる
マイクロサービスを直接呼び出す構成
この構成では、
フロントエンドが 複数サービスの責務を理解し、データを組み立てる必要 がある。
BFF（Backend For Frontend）とは
BFF（Backend For Frontend） とは、
フロントエンドとバックエンドの間に配置されるアプリケーション層であり、
両者の複雑性を吸収・緩和する責務を持つアーキテクチャパターンである。
- フロントエンド専用のバックエンド
- API の集約・変換・最適化を担当
- フロントエンドの都合に合わせた API を提供
BFF を導入した構成
フロントエンドは BFF の API だけを意識すればよくなる。
BFF のメリット・デメリット
メリット
- フロントエンドとバックエンドの 責務を明確に分離できる
- フロントエンドで行っていた API 結果の組み立て処理をバックエンドに委譲できる
- レスポンスをフロントエンドが扱いやすい形にでき、
UI 側のロジックが単純化される - フロントエンド専用 API にすることで
バックエンド変更の影響範囲を最小限に抑えられる - フロントエンドごとに BFF を持つことで、
Web / Mobile など異なるクライアントが独立して進化できる - キャッシュを BFF に集約できる
デメリット
- BFF 分の 開発コスト・運用コスト（監視・保守）が増加する
- BFF が API を集約するため、
通信量やレイテンシが増加する可能性がある - アクセスが一元化されるため、
BFF が障害点（SPOF）になり得る
BFF が向いているケース
- マイクロサービス数が多い
- フロントエンドが SPA / モバイルアプリなど複数存在する
- フロントエンドの変更速度が速い
- API の粒度がフロントエンドに最適化されていない
まとめ
- マイクロサービス化は柔軟性をもたらす一方で、
フロントエンドの複雑化という課題を生む - BFF はその課題を解決するための
フロントエンド特化型のバックエンド - 導入にはコストも伴うため、
チーム構成・システム規模を考慮した判断が重要
参考
- Sam Newman, Backend for Frontends Pattern
https://samnewman.io/patterns/architectural/bff/