はじめに
こんにちは！SIerに入社して１年目の新人エンジニアです。日々の業務で当たり前のように使われている用語で「えっ、それって何？」と思ったものを調べて、自分なりにまとめていきます。
今回は「BFFアーキテクチャ」について調べてみました。
目次
BFFって何の略？
まず最初に、BFFは「Backend For Frontend」の略だということがわかりました。日本語では「フロントエンド専用のバックエンド」といった意味です。
より具体的に説明すると、「フロントエンドとバックエンドの中間に配置され、双方の複雑な処理を緩和させる責務を持つアーキテクチャ設計パターン」、あるいは「バックエンドのAPIから取得したデータをフロントエンド向けに加工するフロントエンド専用のサーバー(API Gateway)」ということです。
なぜBFFが生まれたのか？
従来のシステムでは、バックエンドAPIは「汎用的」に設計されることが多く、さまざまなクライアント（Webブラウザ、スマホアプリ、タブレットなど）からのリクエストに対応していました。しかし、各クライアントの特性やニーズが異なるため、次のような問題が発生していました。
- 必要以上のデータを取得してしまう（オーバーフェッチング）
- 1つの画面表示に複数のAPIリクエストが必要になる
- クライアント側で複雑なデータ加工処理が必要になる
- デバイスごとに最適化が難しい
これらの問題を解決するために、2015年頃にSoundCloudのエンジニアチームがBFFパターンを提唱し、広まっていったようです。
従来のアーキテクチャとの違い
従来のアーキテクチャでは、すべてのクライアントが同じAPIを使用していましたが、BFFアーキテクチャでは、クライアントの種類ごとに専用のバックエンドサービス（BFF）を用意します。これにより、各クライアントに最適化されたAPIを提供できるようになります。
BFFのメリット
フロントエンドとバックエンドの責務分離
BFFを導入することで、フロントエンドとバックエンドそれぞれの責務がより明確になります。フロントエンドはUI/UXに集中でき、バックエンドはビジネスロジックとデータ管理に専念できます。
フロントエンド開発の効率化
フロントエンド開発者が求める形式でAPIを設計できるため、フロントエンド開発の効率が向上します。データの取得や加工処理をBFF側で行うことで、フロントエンドのコードを簡潔に保つことができます。
パフォーマンスの向上
クライアントは1回のリクエストで必要なデータをすべて取得できるようになるため、複数回のAPI呼び出しが減少します。また、不要なデータを除外してネットワーク転送量を削減できるため、特にモバイル環境では大きなメリットになります。
クライアント特性に合わせた最適化
各クライアント（Web、iOS、Android）ごとに最適化されたAPIを提供できます。例えば、画面サイズが小さいスマートフォン向けには、データ量を削減したAPIを提供するといった対応が可能です。
BFFのデメリット
開発・運用コストの増加
クライアントの種類ごとにBFFを開発・運用する必要があるため、リソースやコストが増加します。また、メンテナンスや監視などの運用コストも考慮する必要があります。
通信量の増加と遅延の可能性
API結合によって通信量が増加し、レスポンスに遅延が発生する可能性があります。特に複数のマイクロサービスからデータを取得・集約する場合は注意が必要です。
サーバー障害のリスク増加
BFFはその性質上、サーバー障害などが発生すると依存しているフロントエンド側にも大きく影響が及びます。アクセスの一元化によってリスクが増加するため、適切な対策が必要です。
バックエンドへの依存
BFFはバックエンドのAPIに依存するため、デプロイなど連携が必要になります。バックエンドの変更がBFFにも影響を与える可能性があります。
BFFとマイクロサービスの関係
マイクロサービスアーキテクチャでは、バックエンドが複数の小さなサービスに分割されています。この場合、1つの画面表示のために複数のマイクロサービスからデータを取得する必要があることが多く、クライアント側の実装が複雑になりがちです。
BFFはこの問題を解決するために、マイクロサービスの前に立ち、必要なデータをすべて集約して、クライアントに最適な形で提供します。つまり、マイクロサービスの複雑さをクライアントから隠蔽する役割を果たしています。
まとめ
どのようなアーキテクチャにもメリットとデメリットが存在するので、Netflixのような大手テック企業が採用しているからといって盲目的にBFFを採用するのではなく、システムの特性や要件に合わせて慎重に判断すべきだと感じました。
参考資料