BFFの設計思想　～FatにするかSlimにするか～

はじめに

最近、BFF（Backend for Frontend）アーキテクチャを採用する会社が増え、至る所で見るようになりました。BFFは、特定のフロントエンドアプリケーションに特化したバックエンドサービスを提供するアーキテクチャスタイルです。しかし、BFFと一口に言っても様々な形で導入されており、「Fat」にするか「Slim」にするか決めるべきと考えています。

なお、BFFについては以下の記事でも詳しく解説しています。

https://zenn.dev/ficilcom/articles/graphql-gateway

BFFの導入背景と結果

通常はバックエンドのマイクロサービス化に伴って、フロントエンドの開発生産性を維持するために、BFFは導入されます。しかし、開発が進みプロダクトが成熟するにつれて、BFFにロジックが入り込み、接続エンドポイントも増え、BFF自体が肥大（Fat）化するのが多く見受けられます。
以下のような事象が発生し、BFFが開発のボトルネックになり、開発全体の足を引っ張ります。

• 複数のバックエンドチームが一つのBFFを触っているため、コンフリクトが起こりやすくなる。
• BFFが「いろいろできる」状態なため、パフォーマンスのボトルネックになりやすい。
• チームによってBFF/バックエンドAPIに任せている境界がバラバラなため、コミュニケーションの認知負荷が重いandナレッジがたこツボ化している。

Fat BFFとSlim BFF

BFFというアーキテクチャの性質上、アクセスが集中しやすく、ボトルネックになりやすい部分だと思います。BFFの肥大化に伴って結果的にFat BFFを受け入れるチームは多いですが、そうであるならば最初の段階で設計に組み込むべきです。

Fat BFF

Fat BFFは、ビジネスロジックやデータ処理を多く含む、重厚なバックエンドサービスです。このアプローチでは、BFF自体が多くの機能を持ち、クライアントに提供するデータの前処理や統合を行います。

Fat BFFのポイント

• BFFがDBと直接接続する、もしくは基幹システムと密結合になる。（その他は検索やメール送信といった専業サービスと結合する。）
• データの統合や前処理をBFF側で行いがち。
• BFFが「いろいろやる」ことになるので、NestJSやGoなどの守備範囲の広い技術選定を行う。
• BFFが様々なロジックを持つことを見越して、Clean ArchitectureやDDDなど、ソフトウェア設計も併せて行う。

Slim BFF

Slim BFFは、できるだけシンプルで軽量なバックエンドサービスです。このアプローチでは、BFFは基本的なデータフェッチングやルーティングのみを行い、複雑なビジネスロジックやデータ処理は他のサービス（マイクロサービスなど）に委ねられます。

Slim BFFのポイント

• Slim BFFはロジックを持たない（持たせない）。
• 基本的なデータフェッチングやルーティングに特化させる。
• BFF自体の保守性が高く、スケーリングが容易。

下図はモジュラモノリスの例

弊社の開発ではFat BFFが肥大化した際の技術的負債を回避するため、Slim BFFを実現すべくGraphQL MeshをBFFとして採用しています。
https://zenn.dev/ficilcom/articles/bff-architecture-graphql
https://the-guild.dev/graphql/mesh

GraphQL Meshを採用したことでBFFがロジックを持てない分、NextJSフロントエンドでもロジックを持たせています。NextJSのApp RouterやSearver Actionの発展も、このSlim BFFの採用を後押ししたと思います。

まとめ

BFFアーキテクチャの設計において、「Fat」にするか「Slim」にするかは、プロジェクトの特性やチームのスキル、パフォーマンス要件などに依存しますが、先に決めておくことで、その後の開発指針やメンバー間の認識合わせに大いに役に立ちます。BFFを導入した例は多いですが、どちらのアプローチにもメリットとデメリットが存在するため、各プロジェクトのニーズに応じた最適な選択を行うことが重要です。
この記事が、BFFアーキテクチャの設計における意思決定の一助となれば幸いです。