概要

BFFについて調べたことをまとめる。

BFFとは

Backends For Frontendsの略。Best Friends Forever（ズッ友だよ）ではない。 ‌ 名前の通り、フロントエンドのためのバックエンドサーバーのことで、フロントエンドのためのAPIやHTMLをレスポンスするなどUI・UXのための役割を担っている。 ‌ クライアント（サーバーの呼び出し側）の多様性に応えるのが難しいという問題を、BFFはクライアントごとの要求を整理する形で解決することができる。 ‌

気になったこと

採用言語
- BFFはフロンドエンドのためのバックエンドである故フロントエンド寄りの技術で構成するケースが多いように見受けられる
再構成
- 一度BFFにするとバラすのは大変そう
- 本当にBFFが必要となるまでは採用するのは先延ばしするのが良さそう（本当に必要か？という判断が難しいわけではあるが・・）
アンチパターンとして考えられそうなこと
- バックエンドエンジニアとフロントエンドエンジニア間のコミュニケーション不足
- BFFにUI以外のロジックが多く乗ってしまう
- バックエンドとフロントエンドの結合を一気に行ってしまうビックバンジョイント
フロントエンドの最適化がしやすそう
- APIの呼び出しを最適化することでUIの表示パフォーマンスを改善したりできそう
BFFとDDD
- フロントエンド側でのドメイン整理が必要？このへんはわからない..
APIの集約単位
- どのAPIをどういう単位でグルーピングするか考える難しさがありそう
- マイクロサービスをやっているのなら、BFFではなく別のマイクロサービスを立てるでも良かったのでは？とかなるとBFFのメリットが損なわれそう
マイクロフロントエンドとの相性
- マイクロフロントエンドの知見がなくてﾅﾆﾓﾜｶﾗﾅｲ
- マイクロフロントエンドのコンポーネント構成に影響されそう？
GraphQLとの相性が良さそう
- graphQLを使うならスキーマファーストではなく、コードファーストが向いているという事例
  - cf. なぜGraphQLをコードファーストに統一したのか？型定義の一貫性を保つためのBFF／FE大整理)
可用性
- BFFが複数のバックエンドの集約であるということは、複数のバックエンドの障害に影響を受ける、依存しているということであると思う
- この懸念について、ZOZOさんでは正常に返却できるデータだけはレスポンスをするように工夫しているらしい
  - cf. Backends For Frontends（BFF）はじめました
キャッシュ
- BFF側でのキャッシュも考慮する必要がありそう
タイムアウト・リトライ制御
- 通常のAPIでも考える事項ではあるが、BFFの場合は設定値の調整が少し頭を悩ませそう
デプロイ
- BFFのデプロイとバックエンドのデプロイの足並みを調整する必要がありそう
- デリバリのスピードに関わる
ビジネスロジックを持たない
- BFFではビジネスロジックを持たないのが基本のようだが、ビジネスロジックを完全に切り離すことはできる？できないケースもありそう

参考

所感

BFF自体は知っていたのでさらっとググって終わろうと思っていたのだが、アーキテクチャの可用性や、ビジネスロジックの扱い、クライアントの適切な集約、組織構成との関連など色々考えるポイントが多く面白かった。

自分としてはBFFは結構慎重にならないと落とし穴が多そうという印象を持った。罠みたいなところは見えるけどそれに引っかからないようにうまく作るのは難しそうという感覚を持った。

もしBFFを検討する機会があれば振り返ってみようと思う。