BFF
Backends For Frontends
バックエンドもフロントエンドも複数形であるところがミソ
複数のバックエンドを束ね、複数のフロントエンドからのリクエストを捌く
RESTのようなリソース志向のAPIがバックエンドである想定 ここに各クライアント固有のロジックが入り込むと、バックエンドでフロントエンドの考慮をする必要が出てくる
なのに、バックエンドとフロントエンドのチームが別になっているとコンウェイの法則に逆らうことになる
バラバラのAPIを束ねるAPI層としてBFFを置く
BFFの分割パターン
iOS/Androidで分ける
Mobileとして1つにする
複数のクライアントを束ねるということは、複数のクライアントごとの分岐を許容することになる
別の体験をしてほしい場合はBFFも分けることを推奨
コードの重複問題
共有ライブラリを作る
これがボトルネックとなって拡張性が損なわれないように注意する
別々に実装する
すべて重複させると同じ挙動をしてほしい場合に困る
使う場面
フロントエンド(場合によってはクライアント別)とバックエンドが別チームである
複数のクライアント(Web、モバイルアプリケーション、コンソールアプリケーション)が必要である
関連記事・動画
https://www.youtube.com/watch?v=jfN6HOgURXM
採用している企業としては
Netflix
Twitter
@ITの連載
lacoさんによるバックエンドの考え
Backend for UsecaseとBackend for Resource