BFFってなに？

BFFとは

BFF(Backends For Frontends). 名前の通り、フロントエンドのためのバックエンド。 デスクトップやモバイルなどの クライアントごとに実装されたAPI Gateway のこと。

ほんで、 API Gateway はまたなに？

API Gateway

API Gateway はクライアント（フロントエンド）とバックエンドのレイヤーに存在して、以下のような機能を持っている。

• リクエストのルーティング
• APIを複数呼び出して、結果をまとめる
• プロトコル変換
• 認証・認可
• リクエストの制限
• キャッシュ
• ログの出力
• etc...

上記の全てを実装してからこそAPI Gatewayになるわけではない。 認証や認可はSSOなどを実現するために共通して切り出すこともあったり、ルーティングはロードバランサを使って実現したりすることもよくある。

BFF はこの API Gateway の役割の中で、 APIを複数呼び出して、結果をまとめる 、つまり APIコンポジション をメインとしていると思う。 なぜなら、BFFは クライアントによってBFFのレスポンスが大きく変わる 。

同じマイクロサービスのAPIを使うとしても、クライアントごとに欲しがるレスポンスの形が違うから。

BFFのメリット

BFF を置くことによって得られるメリットを一つは パフォーマンスの改善 にある。 BFFだけでなく、APIコンポジションを行う API Gateway なら共通して得られるメリット。

BFFを置かなく、クライアントでAPIコンポジションを行うことを想定してみよう。 その場合、クライアントは複数のAPIを叩くことになり、大量のリクエストをすることになる。 BFFでAPIコンポジションを行うのであれば、クライアントからのリクエストは 1回 になるので簡単。 それにクライアントで欲しがる形でデータを返してくれるのでクライアント側でデータの操作がなくなるので、コードがシンプルになる。

また、 BFF を置くと、クライアントからAPIを隠せる ようになる。 複数のAPIが存在する際に、それらのAPIを直接叩いたり、データをまとめるのはBFFで行われるのでクライアントではBFFの位置だけ知っていればデータがもらえる。

クラインととAPIをもっと厳密に切り離すことができるので、メンテナンスはより簡単になる。

BFFのデメリット

BFFも一つのマイクロサービスなので、 BFF自体の開発コスト もやはりかかってしまう。 基本的にBFFにはビジネスロジックはなく、簡単な操作しかないが、マイクロサービスである以上は当然テストも必要になってくる。

しかし、個人的に会社で開発する際に　BFF自体の開発コスト　はそこまで気になりはしなかった。 上にも書いたが、BFFにはビジネスロジックはない ので、テストやE2Eも簡単で、実装自体も結構簡単に済むことが多いイメージ。

注意点

BFFはクライアントと近いので下手するとクライアントに大きい影響が出てしまう。 基本的に全てのサービスがそうだが、BFFは特に実装の漏れや不具合が ユーザに直接的な影響をもたらしてしまう ので注意が必要。

また、BFFは複数のAPIを叩くので、一部のデータが欠落しているケースは考慮して設計しないといけない あるAPIのレスポンスがあまりにも帰ってこない場合は、その他のデータだけを返すとか、そもそも早めにエラーを返すかなどは考えるべき。これもBFFに限っての話してはないが、常に意識はする必要がある。

参考

Microservices Patterns

microservices.io - apigateway