WebAPサーバー
Backends for Frontends(BFF)
データベース
で構築されるWebアプリケーションのこと
なぜ興味持ったの？？
近年Web３階層構造が注目され主流になりつつあるためです。
従来のWebアプリケーションは
Webサーバーとデータベースの２つを用いた構造が主流でした。
なぜWeb３階層構造が主流に？？？
増え続ける端末の全てに対応するようにバックエンドを変更していくのは限界があり,
特に複数のUIに対応するようすべてのAPIを変更するのは非効率的であったため、UI処理を専用で行うWebサーバを用いる構造に変化しました。
この時Webサーバはバックエンドとフロントエンドをつなぐという意味でBFF（Backends For Frontends）と呼ばれるようになります。
メリット
処理の負荷分散が容易
処理の負荷分散は文字通り、従来の構造よりも細かくモジュールが分かれているためどれか一つのリソースに大きな負荷がかかるということが少なくなりました。また、もし仮に大きな負荷がかかる場所があるとしてその特定が簡単なため、リソース配分を考えるうえでも利点となります。
保守性が高い
各機能ごとにモジュール単位で稼働しているため障害が発生した場合の原因の特定が容易になる。
また、何か障害が発生した際にその部分を切り離すなどして全体の機能を止めずに機能や性能を落として運用を続けられます
フロントエンドとバックエンドの実装を別々に行える
FEとBEはこのような構成だと明確に分かれます。
BFFとバックエンド間のAPIが定まれば
BFFをフロントエンドエンジニアが、バックエンドやデータベースをバックエンドエンジニアがと分担を明確にすることが可能となり、同時並行で互いの領分や仕事内容を邪魔することなく開発がすすめられます。
デメリット
管理資産が増える
各機能ごとにサーバが必要なため管理資産が増えるというデメリットがあります。
しかし、クラウドやコンテナによる開発が主流となってきた今日これらのデメリットはなくなりつつあります。
注意点
BFFとバックエンドの処理内容を明確にする
BFFとバックエンドが互いにどこまでの処理を行うか、どこまでの責任をどちらが持つかを明確にしておかないと、本来必要だった処理が双方から漏れてしまう可能性があります。
これを防ぐためにも設計段階からBFFとバックエンドのすり合わせを何度も行い、責任範囲を明確にしておく必要があります。
BFFに機能を載せすぎない
BFFはバックエンドの処理の一部を移譲させる形でバックエンドの処理を減らしました。しかし、処理を移譲させすぎるとBFFの負荷が高まり結果として全体の性能が悪化することが考えられます。
BFFはあくまでUIのためのサーバであることを共通認識として持ち、BFFの処理が増えていると思った場合はバックエンドのAPIの仕様を見直すのも一つの手。