ども！一年前に入門したBFF（Backend For Frontend）について一年越しに考えてみました。今回は具体的に作成したアプリケーションに要件を足した場合、Backend For Frontend：BFFの設計パターンで実装した際に得られるメリットをシミュレーションしてみました。BFFはどこの仕事？僕はフロントエンドの仕事だと思ってます。
ご挨拶
ども！ついに仕事で書いているコードよりも文章のほうが多くなった龍ちゃんです。ブログと資料作成で週が始まりました。今日は結構な寒さと雪が降りまして暖房が欠かせないですね。昨日のうちに買い出しに行っていてよかったです。
さて今回は、ざっくりと一年前に「BFFにざっくり入門する」という記事を書いていることを思い出したので、実際にBFFでアプリケーションを構成について考えてみようと思います。本当にこの構成がBFFなのか？ということに関しては、暖かい目で見てもらった方がいいかもしれません。
バックエンド側はGoogle Apps Script：GASで作成した、APIを使用すると仮定します。参考記事としては、以下になります。
それでは、始めていきましょう。
Backend For Frontend：BFFってなに？
復習も含めて、BFFってなんぞ？という部分を書いていきたいと思います。正式にはBackend For Frontendとなります。バックエンドもフロントエンドも登場すると混乱しますよね。
設計パターンの一種で「フロントエンドの情報のために用意する、バックエンドと通信することを前提としたバックエンド」になります。文中にいきなりバックエンドが二回登場しましたが、以下の図を見てください。
位置関係としては、フロントエンドとバックエンドの中間に位置します。複数のバックエンドやデータソースがある場合を想定しましょう。その時に起きる問題としては、それぞれのエンドポイント（URL）に対するアクセスとそれぞれの仕様書になります。控えめに行って地獄ですよね。
つまり、「フロントエンドとバックエンドの中間に中間バックエンドを設置して、バックエンドとの通信をBFFに移譲させ、フロントエンドは中間バックエンドとのみ通信を行う」設計方法のことをBFFといいます。
もちろんメリットもデメリットも存在しています。業務で体験している人に苦労話は任せてラフに書いていきたいと思います。
最初にBFFを知った際に感じた感想としては、BFFをちゃんと作りさえすればフロントの業務は、デザインとデータの更新タイミングの管理だけになるな～でした。もちろん開発・運用コストとリスクは無視できません。
その一方で、開発者が複数いて速度を求められる場合（プロトタイプ作成など）は、ビジネスロジックの整理、BFFの仕様に落とし込み、モックを作成してバックエンドとフロントエンドの開発をするという流れが速くなる気がします。
個人開発の現場では、マイクロサービスと連携が取りやすくなるなどのメリットもあります。
BFFはフロントエンドの仕事？バックエンドの仕事？
こちらは永遠のテーマになるかと思います。最近の自分の考えでは、フロントエンドの仕事にした方が良いかと思います。もちろん、どこに特化したフロントエンドエンジニアなのかという話は必要になります。
複雑で大規模なシステムを開発をしている場合は、BFF専門にバックエンドエンジニアを置くという決断もできると思います。ですが、小規模でスピード感が必要となる開発の現場においてはフロントエンドが担当することによるメリットがあると思います。
これは、BFFがフロント用に最適化されたバックエンドであるという点も関係しています。レスポンスがそのまま表示に関係するのであれば、型定義のタイミングからフロントの観点が入ることによって画面構築に必要な情報が手に入るかと思います。
そして、その前提を正しく認識しておくことで、デザイナーの方に対するレスポンスにフロントエンドエンジニアのみで対応することができます。最悪、仕様変更にあったとしても認識のすり合わせが必要なくなります。フロントエンドエンジニアの業務がどこまでか？という話もできそうですが、現在の経験ではBFFはフロントエンドの仕事だと思っています！
さっくりとBFFを構成してみる
さて、一から構成を考えると空想話にもなってもったいないので、昔作成して現在も社内で稼働しているシステムを対象に話をしていきます。こちらのブログで解説したシステムを流用します。
こちらのシステム構成図がこちらになります。いったんセキュリティ的に問題があるという点については目をつぶっておいてください。
構成としては、フロントエンドのみで運用しています。もしこちらのシステムに利用頻度を計測するためにログを取るという処理を挟むと仮定します。現状の構成のまま解決策に飛びつく場合は、以下の対応になると思われます。
- Firebase Firestoreにログを保存用のDBを用意して、DBの一部として情報を保存する
別に問題はありませんが、その要件の後ろには利用者の分析をスプレッドシートで分析して社内に共有したいという要望が隠れている可能性があります。もちろん、やりたいことだけでなくその後ろに隠れている要件のヒアリングも重要です。
この前提を踏まえて、システムの構成を以下のように変更します。
ログの処理をGASで作成したAPIに切り出すことで、保存先を直接スプレッドシートにすることができ、その後の要件などもさくっと解決することができます。データの保存先を一時的にスプレッドシートに変更したい場合なども、エンドポイントへの変更を加えることなくBFFのみの変更で済みます。めったにないかと思いますが、データの保存先をAzureに移管するとなった場合も同様ですね。処理をBFFに切り出すことで得られるメリットは意外とあることがわかるかと思います。
GASとBFFの相性が意外と良いという話
少しコラム的な内容になります。GASでAPI作成といった記事を作成していますが、ちゃんと実行可能APIとしてデプロイすればよいのですが、ウェブアプリとしてデプロイする場合では、以下のような制限があります。
この条件周りは、単一の機能を持ったバックエンドとして取りまわすことができそうです。
もちろんセキュリティ的観点からは、「実行可能API」としてデプロイしたほうが良いです。BFFのアクセス部分においては、トークンの検証などもしておいた方が圧倒的に良いです。個人開発でセキュリティ度外視で開発を進めている場合はいったん見なかったことにして、開発が終わったらデプロイしたシステムをクローズしておきましょう。
おわりもす
どもども！一年前の記事を加筆修正するという取り組みでした。2023年2月16日に執筆をしていたので、タイミング的に神っていましたね。一年仕事をして、ブログを100本ほど執筆したので見比べながら見てもらえれば面白いかなと思います。それにしてもBFFって聞くとBest Friend Foreverが先に出てくると、書き出しで書こうとして一年前の自分が全く同じことを書いていて、案が変わらんもんやなと笑っていました。
さて！今日はこの辺で！仕事を終わります。大寒波が来ているので、皆さんあったかく！
Twiiterもお願いします。
