概要

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ではビジネスロジックを持たないのが基本のようだが、ビジネスロジックを完全に切り離すことはできる？できないケースもありそう

参考

• Pattern: Backends For Frontends
• BFF（Backends For Frontends）超入門――Netflix、Twitter、リクルートテクノロジーズが採用する理由
• BFF(Backend for Frontend)
• BFFに取り組む開発者たちが語る「UIT#3 The “Backends for Frontends” sharing」
• BFF/SSRの話
• セッションレポート「Backends for Frontendsこそサーバーレスで楽をしよう!!～本来の目的に集中するために～」を見てBFFについて学習したことまとめ
• Dividing frontend from backend is an antipattern
• BFFとmicroservicesアーキテクチャ
• GraphQLを活用したBackend for Frontendへ リアーキテクチャした話
• BFF（Backends For Frontends）実践における3つのアンチパターンと、その回避策
• BFF（Backends For Frontends）の5つの便利なユースケース
• Backends for Frontends (BFF) 再考
• More coverage on BFFs
• Embracing the Differences : Inside the Netflix API Redesign
• BFF \@ SoundCloud
• Moving to Microservices at SoundCloud with Lukasz Plotnicki
• Backends For Frontends（BFF）はじめました
• Backends for Frontends パターン
• BFFとはなんなのか？
• 新規開発においてBFF(Backend for Frontend) を採用すべきか
• Backend for frontend (BFF) pattern— why do you need to know it?
• 流行りのBFFアーキテクチャとは？｜Offers Tech Blog
• なぜGraphQLをコードファーストに統一したのか？型定義の一貫性を保つためのBFF／FE大整理
• Are BFF (Backend for Frontend) and DDD mutually exclusive?
• フロントエンドエンジニアは Micro Frontends の夢を見るか

所感

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

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

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