概要
BFF（Backend For Frontend）は、フロントエンドごとに専用のバックエンド層を用意するアーキテクチャパターン。主に、複雑な UI を持つアプリケーションにおいて、データの取得・変換・整形・統合を行う中間層の役割を果たす。
なぜ BFF が必要か
- API の粒度調整: REST API や GraphQL など、バックエンド API が汎用的すぎる場合、画面単位で最適なレスポンスを得るのが難しい。
- データ統合: 複数のマイクロサービスやサードパーティ API からデータを集約し、フロント用に整形できる。
- UI ロジックの吸収: パーソナライズ、フィルター、ソートなど、表示上のロジックを BFF 側で担当し、フロントをシンプルに保てる。
- 変更に強くなる: UI の変更に伴う API 仕様の変更を、BFF が吸収できることでバックエンドとの連携が柔軟になる。
BFF の構成例
- BFF + REST API: 既存の REST API 群を集約して、画面単位に構成し直す。
- BFF + GraphQL: 各データソースを GraphQL で統合し、クライアントからの柔軟なクエリに応答。
- BFF + tRPC: フロントと型を共有する RPC ベースの通信。TypeScript と親和性が高く、Next.js などで活用。
- BFF 内蔵型: Next.js（App Router）や Nuxt などのフルスタックフレームワークで、ページ単位の API と UI を統合。
実装技術の選択肢
| 技術 | 特徴 | 向いているケース |
|---|---|---|
| Express | 柔軟で自由度が高いが、手動管理が多い | 小〜中規模 BFF |
| NestJS | DI/モジュール構成があり、大規模に強い | 複数チーム BFF |
| Fastify | 高速で型安全な実装が可能 | パフォーマンス重視 |
| Next.js | App Router で UI と API を共存可能 | UI 主導プロダクト |
| tRPC | 型共有と RPC 構成が簡単。API 定義が不要 | TypeScript 環境向き |
BFF と他の技術の比較
| 目的 | BFF | GraphQL | REST |
|---|---|---|---|
| UI 特化 | ◎ UI に合わせて設計可能 | △ クエリ調整はできるが共通スキーマ前提 | △ 一般的に粒度が汎用的 |
| 複数データ統合 | ◎ 中間層で自由に統合可能 | ◎ Schema で統合できる | △ クライアント側での統合必要 |
| 型安全 | ◯ zod, TypeScript 等で担保可能 | ◎ GraphQL スキーマで厳格 | △ OpenAPI ベースに依存 |
| 保守性・テスト | ◎ UI 単位で分離しやすく、疎結合 | △ リゾルバが肥大化しがち | ◯ エンドポイントごとに明確 |
BFF 設計のポイント
- 画面・機能単位で API を切る（Component API 的な発想）
- バリデーション・型安全の担保（zod や OpenAPI）
- フロントと密に連携する設計（BFF はフロントチームが主体）
- 認証・認可を含めるか明確にする
- 外部 API・DB アクセスの抽象化と責務分離
まとめ
BFF は「フロントの都合に合わせて最適なバックエンドを構成する」ための手法。汎用的な API に依存するのではなく、フロントごとの要件・変更・表示ロジックを柔軟に扱えるのが最大の利点。Next.js や tRPC といった現代的ツールと組み合わせることで、BFF はますます実践的な選択肢になっている。