概要
こんにちは、Offers を運営している株式会社 overflow の Software Engineer（主戦場はフロントエンド）の Kazuya です。2022 年 2 月入社でそこまで日が経っていないので、今回は社内の技術スタックではなく、今後社内でも検討されるかもしれない「BFF」について触れていきたいと思います。BFF（Backend For Frontend）導入することで得られるメリット/デメリット、GraphQL を用いた技術スタック事例など紹介していますので、ぜひ参考にしてもらえればと思います。
BFF とは？
BFF とは、Backend For Frontendの略称で、「フロントエンドとバックエンドの中間に配置され双方の複雑な処理を緩和させる責務を持つアーキテクチャ設計パターン」のことです。これだけだと分かりづらいので簡単にまとめると、「バックエンドの API から取得したデータをフロントエンド向けに加工するフロントエンド専用のサーバー(API Gateway)」です。
マイクロサービス化や Web アプリケーションと iOS アプリケーションなどを両立させる際、API サーバーへのリクエスト負荷やレスポンスのパターン増加による処理の複雑化などの課題が発生します。そこで中間に BFF レイヤーを配置することで、フロントエンドとバックエンドの連携における処理が分散され、アクセスフローがシンプルになります。
導入すべきケース
前述しましたが、BFF は「マイクロサービス化における課題を解決するためにできたアーキテクチャ」という側面を持っているため、マイクロサービス且つフロントエンドにおける実装は複雑化してきた段階で検討するのが良いと思います。導入時は、フロントエンド、BFF、バックエンドそれぞれが持つ責務を明確に定めた上で、開発していくと本来の責務から外れてより複雑化するといった問題が発生しづらくなります。
担当するエンジニアは？
BFF は、フロントエンド開発の補助をする形になるため、基本的にはフロントエンドエンジニアが開発を担当します。
バックエンドエンジニアは API を始めとした BFF のリソース管理を担当します。リソースの管理をする際に「Open API（Swagger）」を使って API ドキュメントの作成すると、リクエスト値やレスポンス値などが可視化され、BFF との API 連携を効率化できます。
BFF のメリット・デメリット
メリット
- フロントエンドとバックエンドが持つ責務の分離できる
- フロントエンドで API からデータ構築するコストをバックエンドに委譲できる
- レスポンスをフロントエンドが扱いやすい形にすることで処理を簡略化できる
- フロントエンドに合わせた仕様にできるため、依存の広がりを抑制できる
- バックエンド要因によるブロックが無くなり、開発体験を向上
デメリット
- 開発コストと運用コスト（メンテナンスや監視など）が増加する
- API 結合による通信量の増加と遅延が発生する可能性がある
- アクセスの一元化によってサーバー障害によるリスクが増加する
- バックエンドに依存するため、デプロイなど連携が必要
技術スタック事例
GraphQL / NestJS
BFF は前述した通り、フロントエンド開発を補助する側面が強いため、フロントエンド側に合わせた値を返せる「GraphQL」との相性は良いです。また、BFF はバックエンドを呼び出してフロントエンド向けに加工する以外のロジックは基本的に存在しないため、記述量が少なく、フロントエンドエンジニアが開発をしやすいTypeScript で書けるフレームワーク「NestJS」が採用候補になりました。NestJS であれば、GraphQL に関するプラグインが豊富で導入も容易です。
GraphQL を採用する際は、スキーマファーストとコードファーストのどちらを採用するかという課題に必ず直面します。個人的には、BFF はフロントエンドエンジニア側が開発を担当することになるため、スキーマとコードを同期させて開発するスキーマファーストのより、コード管理だけで済むコードファーストの方が BFF の思想的にマッチしているように感じました。
そもそも NestJS とは？
NestJS とは、「Node.js のサーバサイドフレームワーク」です。特徴は以下の通りです。
- TypeScript に対応しているため、保守が容易なアプリケーション開発が可能
- REST API、GraphQL の両方に対応している
- 拡張性が高く柔軟な実装ができる
- 公式ドキュメントがわかりやすい
- Angular ライクな開発
モダンなフロントエンド環境で採用率の高い TypeScript で書けるため、フロントエンドエンジニアも参入しやすく、キャッチアップが比較的容易です。個人的には、拡張性の高さとバックエンドとフロントエンドにおける型定義の一元化を容易にできる点も良いと感じています。
graphql-codegen
GraphQL を採用した場合、フロントエンド側でぜひ導入したいのが通信メソッドと型ファイルを自動生成してくれるプラグイン「graphql-codegen」です。コマンド 1 つで GraphQL スキーマを元に型定義や hooks を生成してくれるため、フロントエンドにおけるリクエストを最適化しつつ、実装コストも削減できます。
まとめ
本記事では、最近流行りの BFF のアーキテクチャについて紹介しました。様々なアーキテクチャについて知っておくことで、技術選定の幅が広がり、実装における柔軟性も上がると思います。本記事で少しでも理解の助けになっていれば幸いです。
いいねしていただけると記事執筆の励みになりますので、参考になったと思った方は是非よろしくお願いします！
関連記事
副業転職の Offers 開発チームがお送りするテックブログです。【エンジニア積極採用中】カジュアル面談、副業からのトライアル etc 承っております💪 jobs.overflow.co.jp
Discussion