BFFでBest Friend Forever(ズッ友)のほうが出てきてしまうのでざっくりまとめ
意味
文字通りでフロントエンドのためのバックエンド機能のことを指す。
おそらくの呼称出典資料
SoundCloudにいたPhil Calçado氏が提唱したのが最初（の様子）
Our original idea was to have different back-ends for different front-ends. The term BFF was coined by our Tech Lead for web, Nick Fisher (my initial suggestion was BEFFE, but our Dutch-speaking team mates vetoed that option).
Google和訳力を使うと以下のような意味
私達の原初のアイデアはフロントエンドごとに異なるバックエンドを用意することでした。BFFという用語は、WebのTech LeadであるNick Fisherによって造られました（私の最初の提案はBEFFEでしたが、オランダ語を話すチームの仲間はそのオプションを拒否しました）。
BFFの出来た経緯と役割
マイクロサービス化が進むと、モノリシックなアプリよりもでデータの拠り所が分散する。その結果、フロントエンド（Webページを描画するJSなどの機構や、スマートフォンアプリ）はそのデータを取りに行くために複数の場所にアクセスする必要が出てくる。そのため1画面を構成するために異様な量のAPIにアクセスする必要が出てくる。
この内容を回避するための方法として、フロントエンドのためのバックエンドという考えとしてBFFというアイデアができた。
BFFは複数のサービスのデータを束ねて管理することでフロントエンドで個々のデータを取得することを代行するバックエンドとシステムとして構成する。こうすることでフロントエンドがアクセスする対象のAPIは少なくなり、アクセスする先はグッと減らすことができた。
BFFのもたらすもの
メリット
- フロントエンドが汎用的に用意されたAPI(Public Service API)から必要な情報を構成するための手間をバックエンドに委譲することができる
- BFFはフロントエンドの都合で変更できるので、依存の広がりをそこで抑制することができる
- BFFが下位互換性を維持できれば、それより後ろのサービス群のバージョン変更への依存性は薄くすることができる
デメリット
- BFFごとに重複したロジックが作られがち
- ただコンテキスト含めて本当に同じロジックであれば別途サービスを作り出せばいい
- フロントエンドの複雑性をバックエンドに移しただけではあるので、バックエンドに移したことで複雑性が解決するわけではないのでそこに向き合う必要はある
