仕事で複数のバックエンドから一つのクライアントと疎通するような構成の可能性があり、BFFが使えるかもということで調べてみました。
#対象者
- BFF(backend for frontend)の概要を知りたい方
- どういったメリット、デメリットがあるかを整理したい方
#概要
BFF(backend for frontend)とは簡単にいうと、クライアントとバックエンドの中間に位置し双方の複雑性を吸収するような作られたサーバーのことです。雑に書くとこんな感じです。
これが必要になった、背景はクライアントの端末の種類が増加したことそれに伴うロジックの増加です。
例えばweb,スマホ版web,スマホアプリ、デスクトップアプリなど複数のクライアントが登場し、それぞれにメッセージやコンテンツの出しわけを実装しようとすると、クライアント側のコードが複雑化し、冗長なコードを書かざる追えない状態になります。
そういった背景から、複数のバックエンドから情報を取得し適切な形に整形するなどのロジックを持つサーバーを導入することで、クライアントはUI/UXに注力するようにしたのがBFF登場の経緯です
#BFFのメリット
APIの集約
シンプルにクライアントはBFFに対してのみAPIを投げればよく、複数のバックエンドに対しての対応や加工などをクライアント側が気にしなくてよくなります。また、バックエンドからの複数のレスポンスをクライアントが求める形に適切に加工して返すことができるので、クライアントの処理も少なくできます。
バックエンドの差異の吸収
例えば、バックエンドの一部がgRPCで他がRESTで他がWebsocketなどのバックエンドの仕様や差異などを全て吸収できるので、複数の種類のバックエンドに対応できます。
フロントエンドとバックエンドの分離
バックエンドとクライアントが直接通信を行う場合そのプロトコルは一致させないと行けませんでしたが、BFFを挟む場合はBFF <-> クライアントとBFF <-> バックエンドは全く別の通信になるので、 BFF <-> クライアントのみ GraphQLで BFF <-> バックエンドは RESTとのような柔軟な調整ができます。
複数にまたがる関心の分離
雑な言い方ですが、BFFに認証や、権限、キャッシュなど処理を置くことで、クライアントサイドとバックエンドサイドにまたがるような処理を取り去りシンプルな形で保つことができます。
#BFFのデメリット
サーバーの開発と保守の手間
BFFもソースコードを持ち、実際に動くサーバーのため、それらに対する監視やデプロイなどの手間が当然増えます。
デプロイのタイミング
BFFはバックエンドと密にやりとりをするため、例えばバックエンドのAPIの仕様変更をした場合BFFも変更して同時にデプロイしないと障害の原因になります。そういったデプロイに対して考えることが増えます。
通信量の増大と遅延
通信が増えるため、通信量が増大し、データを取得するために必要な経路が増えるためデータ取得にかかる時間は当然増えます。なので相応の増強や対処が必要になります。
コードの冗長化
BFFが持つAPIとバックエンドが持つAPIの機能がほぼ一致するケース、例えばユーザー一覧の取得APIなど、機能や関心ごとが一致する場合はほぼ同じコードを書かないと行けないため、コードが冗長化します。
#実装方法
仮にバックエンドがRESTの場合BFFはroutingとHTTP Requestの機能さえ持っていればBFFは実装できます。クライアントとバックエンドの疎通の条件にもよりますが、ただ実装するだけなら難易度はそんなに高くないと思います。
複数のプロトコル対応やクライアント間をgraphQLでしたい場合は EnvoyやApolloなどサーバーを適切に考えないと行けないです。