トレタのフロントエンドエンジニア武市です。

トレタではマイクロサービスを採択していることにより高い設計力が求められます。品質の高いソフトウェアを開発をする為に、求められる技術レベルがかなり高くなりました。前職ではモノリシックアーキテクチャだったこともあり、日々勉強する毎日です。

今回の記事ではトレタでも採択しているBackends For Frontends（以後BFF）について理解が不十分だったので勉強した内容を書いていきたいと思います。

BFFって美味しいの？

先に結論を述べさせていただきますと、すごく美味しいです。
BFFを一度召していただくとBFFなしの開発は考えられない、もうBFFなしでは生きられない。
そう思うことでしょう。

そもそもBFFとは

BFFとはアーキテクチャパターンの1つです。
フロントエンドとバックエンドの中間に[フロントエンド専用のサーバー]を配置するアーキテクチャ設計パターンです。
BFFの役割としては大きく分けると二つあります。

複数のサービスへのリクエストを集約する
バックエンドから取得したデータを加工してフロントエンドに返す

このアーキテクチャを採用することで双方の複雑さが緩和されます。

BFF登場までの背景

BFFはマイクロサービスアーキテクチャ化における課題を解決する為に生まれたアーキテクチャです。
1つのプロダクトを運用していると、どんどん機能や要件が増えていきます。サービスが増えるにつれAPIが増加、エンドポイントも増えることになります。Webアプリ,iOSアプリなどクライアントの端末が増えたことでレスポンスも複雑になります。

本来バックエンドとしての役割とはデータベースからデータの取得、更新、削除があり、
フロントエンドはユーザー体験を向上させる役割があります。
データの加工やAPIのルーティングなどはバックエンド、フロントエンドの本来の役割としては責務外となります。BFFを採用することでこれらの問題が解決されます

BFFのメリット

初期表示の高速化
- クライアントのデバイス性能によっては大きく変わってしまう時間の掛かってしまう処理をBFFに持たせることで初期表示を高速化することができます。
エラーハンドリング
- アプリに不正なデータが入ってこないようBFFで制御することができます。
データの整形
- BFFにadapterを配置してフロントエンドに整形された状態で渡すことによりユーザー体験を向上させる役割だけに集中することができます。
APIの集約
- マイクロサービスアーキテクチャなど複数のバックエンドへリクエストをする際Proxyとしての役割を持たすことができるので、　クライアントからのエンドポイントは一つに集約することができます。

まとめ

各プラットフォームが増える毎にBFFは増えていくのが基本的には望ましいが、冗長になります。そもそも役割が違うのでそれは許容するべきかなと感じるが。一つの体験につき一つの BFF (one experience, one BFF) という考え方もあるのでケースバイケースだなと感じました。

これからは日々勉強していることを発信していきたいと思います。
ありがとうございました。