マイクロサービス化における開発作業を効率化する「フロントエンド用バックエンド」を解説：単なるサービスメッシュではない、そのメリットとは

TechTargetは「フロントエンド用バックエンドパターン」に関する記事を公開した。これは、ソフトウェアをマイクロサービス化する際に課題となりがちなフロントエンドの開発作業を簡素化するアーキテクチャだ。

[Raghu Karan Adapala，TechTarget]

　TechTargetは2024年5月13日（米国時間）、「フロントエンド用バックエンドパターン」に関する記事を公開した。

フロントエンド用バックエンドパターンの仕組み（提供：TechTarget）

　「フロントエンド用バックエンド」（Backends For Frontends　以下、BFF）パターンは、API層を使ってデータの前処理、呼び出しと応答などを処理し、マイクロサービスにおけるフロントエンドの開発作業を簡素化するアーキテクチャのことだ。本稿ではその仕組みやメリット、実装方法を解説する。

API層で頻繁な呼び出しやデータの前処理を効率化

　多数のマイクロサービスで構成されたソフトウェアを再設計する場合、フロントエンド開発が課題となることがある。「React」や「Angular」のようなライブラリやフレームワークを利用したアプリケーション（以下、アプリ）にログイン処理を実装するだけでも、以下のようなサービスと複数回のやりとりが必要になるからだ。

• シングルサインオン（SSO）のための認証サービス
• ユーザーの権限を確立するための認可サービス
• 個人向けにカスタマイズした「ようこそ」の画面を表示させるパーソナライズサービス
• ユーザーに関するデータを読み込むプロファイルサービス

　その上、ReactやAngularを利用するアプリは、必要な全ての情報を集めるために特定のサービスを複数回呼びすこともある。

　こうしたやりとり全てに対処する方法の一つが“BFFパターン”だ。

　BFFパターンは、フロントエンドとバックエンドの間に“インテリジェントなAPI層”を設け、そこでデータの前処理、複数のマイクロサービスへの呼び出しの統合、さまざまなタイプのクライアントに対する応答の最適化などを実施する。これによって、アプリのパフォーマンスが向上し、フロントエンドの開発が簡素化されるという仕組みだ。

BFFマイクロサービスパターンのメリット

　BFFパターンは、次のような方法でフロントエンドの開発をシンプルにする。

• アーキテクチャの複雑さを隠す
• 「前処理」の仕組みを提供する
• 特定のフロントエンドアプリに対応したカスタムエンドポイントを提供する
• さまざまなクライアントのタイプに対応したカスタムデータ交換フォーマットを提供する
• クライアント別のカスタマイズを容易にする

　次に、BFFパターンが提供する機能について詳しく説明する。

さまざまなタイプのデバイスとクライアントをサポート

　BFFパターンは単なるサービスメッシュ（マイクロサービス間の通信を管理するインフラ）ではない。BFFパターンの主な目的は、多様なクライアントやデバイスの特定のニーズをサポートすることだ。例えばモバイルデバイスは、ブラウザベースのアプリとは異なるネットワーク機能を持っている場合がある。IoT（Internet of Things）デバイスやマルチメディアプレーヤーのデータ転送形式やエンコード形式は、「Android OS」デバイスと異なるかもしれない。

　BFFパターンは、そうした特定のタイプのクライアントニーズに応えるため、フロントエンドアプリ（またはクライアント）のタイプ別に専用のバックエンドマイクロサービスを作成する。そのため、1つ目のBFFは「iOS」デバイス専用、2つ目のBFFはWebブラウザ専用、そして3つ目のBFFは音声で起動するロボット用にする、といったことが可能だ。

クライアントデバイスの要件が大きく異なっていても、BFFであればデバイスごとにカスタマイズできる

　もし、単一のエンドポイントで各タイプのクライアントをサポートしようとすると、多くの場合、“機能”が犠牲になる。しかし、クライアントアプリごとにBFFを作成すれば、その心配はなくなる。BFFが各クライアント専用のエンドポイントを提供するからだ。

　動画配信サービスのNetflixは、BFFパターンを使って、バックエンドサービスとクライアントプラットフォーム（Webブラウザ、モバイルアプリ、スマートTVなど）との間のコミュニケーションを最適化している。音楽ファイル共有サービスを提供しているSoundCloudも同様にBFFパターンを使用している。

リソースの使用効率を高める

　BFFのAPI層が処理するのは、バックエンドと複雑なやりとりをするモバイルアプリやWebページではなく、ロジックと集計ルーティンだ。BFFを使うことで、通常なら7〜8回は必要な呼び出しが1回で済むようになる。

　BFFパターンは、簡単に使いやすい形式でクライアントに応答を返す。BFFでデータを前処理するため、クライアント側では応答をレンダリングする前にコンピューティング能力を無駄使いしなくて済む。要求と応答のサイクル数が減ることで、待機時間も短縮される。

開発者の労力を最大限に生かす

　BFFパターンは、バックエンドとのやりとりの中で発生する可能性のあるエラーをキャプチャーし、フロントエンドが簡単に処理できるものに変換する。一般的にBFFの構築と管理はフロントエンドチームが担うため、エラーをキャプチャーしてクライアントに応答を返す最善の方法はフロントエンドチームが熟知しているはずだ。

　複数の「RESTful API」の呼び出しを管理し、結果を正しく集約する作業は大切なことではあるが、熟練のフロントエンド開発者の貴重な時間を使うほどではない。フロントエンドチームによって管理されるBFFパターンは、クライアントと他のバックエンドサービスとのやりとりを処理するだけでなく、フロントエンド開発者の技術的な負担も軽減する。

BFFパターンを既に利用している可能性がある

　明確に意図していなかったとしても、マイクロサービスアーキテクチャが適切に設計されていれば、既にBFFパターンを利用している可能性がある。フロントエンド開発者は、バックエンドの呼び出しを管理する、単一の、再利用可能な、簡単にテストできるAPIを望んでいる。そのため、このやり方に正式名称があることを知らずにBFFパターンに従っている場合がある。