📝

【BFF】BFFってなに？

に公開
frontend
バックエンド
フロントエンド開発
idea

BFFとは？

BFFとは、Backends for Frontendsの略で、フロントエンドとバックエンドの間に位置する専用のバックエンドサービスを指す。役割としては、モバイルアプリやウェブアプリなど異なるクライアントのニーズに合わせて最適化されたAPIを提供すること。マイクロサービス環境では、各フロントエンドが必要とするデータを効率的に取得・加工する中間層として機能する。複数のバックエンドがある場合は、それらを統合してフロントエンドにとって使いやすい形でデータを提供する。

[Frontend] → [BFF] → [Backend API] → [DB]

1. BFFが必要とされる背景

1.1 API構成の検討

複数バックエンドへの問い合わせをフロントで組み合わせると：

  • リクエスト数が増える（特にモバイルで致命的）
  • クライアントロジックが肥大化する
  • 統一的なエラーハンドリングが難しくなる

BFFを配置することで、これらの組み合わせ処理をバックエンド側に集約できる。

1.2 バックエンドプロセスの複雑化

複数プロセスや外部サービス連携が増えるとフロントで直接扱うのは困難。BFFは複雑さを隠蔽してシンプルなインターフェースを提供する。

1.3 クライアントごとの要件の乖離

  • Web：情報量が多く、複雑な UI が求められる
  • Mobile：通信量抑制・省電力・軽量レスポンスが求められる
  • 管理画面：バルクデータや高速フィルタリングが必要

単一 API でこれらを賄うとレスポンス肥大化や API 仕様の複雑化が発生する。

1.4 モダンフロントエンドの高速な変更サイクル

UI の改修は頻繁に行われるが、ビジネスロジックを持つバックエンド API は簡単に変更できない。その差を吸収する層としてもBFFは機能する。

2. BFFのメリット

2.1 複数のバックエンドプロセスを統合可能

BFFは複数プロセスや外部APIからデータを集約し、1つのエンドポイントとして提供できる。

2.2 フロントエンドに最適化されたデータ構造

画面レンダリングに必要なデータだけを返せるため、

  • API レスポンスが軽量になる
  • フロントでの複雑なデータ加工が不要になる

2.3 バックエンドの責務を分離できる

バックエンドはビジネスロジックに集中し、フロント向けの整形・集約など UI 依存処理をBFFに任せる。

2.4 認証・セキュリティの吸収

ログインセッションの管理や認可ロジック、cookieの扱いなど、クライアントごとに異なる認証要件をBFFで一元管理できる。

2.5 パフォーマンス最適化

  • API Composition によるリクエスト削減
  • キャッシュ戦略の柔軟化
  • データのプリフェッチや最適化をBFF層で実施可能

3. BFFのデメリットと注意点

3.1 増える運用コスト

フロントごとに API が分かれるため、BFFが複数存在すると保守コストが増える。

3.2 過剰分岐のリスク

「iOS 用」「Android 用」「Web 用」など細かく分けすぎると管理が煩雑になる。

3.3 ビジネスロジックを混入させない設計が重要

BFFは UI 最適化のためのバックエンドであり、ビジネスロジックを持つべきではない。ここが曖昧になると責務が崩壊する。

4. BFFの実装構成

4.1 開発言語

よく使われる言語：

  • JavaScript / TypeScript
  • Python
  • Java
  • Go
  • Ruby

4.2 技術スタック例

Node.js ベース

  • Express
  • Fastify
  • NestJS
  • Next.js / Nuxt.js（API Routes）

Python ベース

  • Flask
  • FastAPI

Java ベース

  • Spring Boot
  • Micronaut

Go ベース

  • Gin
  • Echo

Ruby ベース

  • Rails API モード
  • Sinatra

5. フロントエンド・BFF・バックエンド間の通信プロトコル

5.1 フロントエンド - BFF

  • REST API：シンプルで広く使用
  • GraphQL：クライアントが必要なデータを柔軟に取得
  • gRPC-Web：高性能な通信が必要な場合
  • WebSocket：リアルタイム通信が必要な場合

5.2 BFF - バックエンド

  • REST API：多くのバックエンドが対応
  • gRPC：高性能なサービス間通信
  • メッセージキュー：非同期処理が必要な場合（例：RabbitMQ、Kafka）

6. BFFを導入すべきか判断する基準例

  • 複数クライアント（Web、iOS、Android など）が存在する
  • クライアントごとに異なるデータ要件がある
  • フロントエンドの変更頻度が高い
  • API レスポンスの最適化が必要
  • クライアント側での複雑なデータ集約が発生している
  • 認証・セキュリティ要件がクライアントごとに異なる
  • パフォーマンス改善が求められている
  • バックエンドの責務を明確に分離したい
  • チームの開発速度を向上させたい

7. BFF設計について

7.1 画面単位の API 設計

UI ごとに必要なデータの組み合わせを API で提供する。例：

  • /home
  • /product/detail
  • /user/dashboard

7.2 責務境界の明確化

  • フロントエンド：UI ロジック、状態管理
  • BFF：データ集約・整形、認証、キャッシュ
  • バックエンド：ビジネスロジック、データ永続化

7.3 仕様変更に強い API 設計

画面構造の変更に耐えられるよう、極力フロント志向の API にする。

7.4 ロジックの共通化

複数BFFがある場合は共通処理をライブラリ化して重複を防ぐ。

8. まとめ

BFFはフロントとバックエンドのギャップを解消し、柔軟性・拡張性を高めるアーキテクチャです。
適切な責務分離と運用設計を行えば、BFFはチームの生産性と品質を高める強力なアプローチになります。

Discussion