正式名称
Backends For Frontendsの略
https://samnewman.io/patterns/architectural/bff/
とは
クライアントサイドに特化した機能提供を行う。
背後により特化したAPIを構える。
BFFは、クライアント端末の種類によって分ける。
似たもの
- MVCアーキテクチャのView
- 三層アーキテクチャのPR層
メリット
- 多様な端末に対する対応するBFFを列挙することで個別対応する層と統一的に利用するバックエンドAPIを分離する
- UI要件におけるバックエンド要件をインタフェース化できるので、バックエンドと役割分担しつつ、バックエンドAPIをスタブ化して開発できる
アクセス端末が多種にわたるようなサービスの場合は効果があると思われる。
PC,モバイルくらいのサービスなら別に要らないと思う。
Q:レスポンシブなサイトはBFF分割されない？
レスポンシブ化するだけで、BFF分割する要件が消えるならBFF必要案件ではないと思う。
採用基準
BFFは、クライアントからのリクエストプロトコルが統一的に記述できないから選択するものだと思う。
BFFはやりたくてやるものではなくて、やらざるを得ないからやるものだと思う。
何らかの理由でHTTPリクエストを発行できない特殊端末がサービス提供先にあるから対応する、とか。
複数のAPIを束ねたいなら
API Gatewayサービスがあるのでそちらの採用を検討する。
- GoogleのApigee
- AWSのAmazon API Gateway
- Azure API Management
独自にBFFを作る理由がそれでもあるのか、よく検討したい。
事例
Line
実践マイクロサービス ─ コンポーネント分割やトラブル回避の考え方をLINEの導入事例に学ぶ
マイクロサービスの分割の事例紹介になっているが、先頭のShop-proxyとLINE STOREはBFFが別れていると見ることもできる。マイクロサービスがBFFかそうでないかは置いといて。