Decathlon社は、全社的な推奨事項としてBackend For Frontend (BFF)アーキテクチャパターンを確立し、エンジニアリングチームでの採用のためのガイドラインを提供した。この4部構成のシリーズでは、このパターンを紹介し、その利点と潜在的な落とし穴を探る。同社はまた、BFFパターンを使用する代替案を共有し、アーキテクチャ上の検討事項をレビューしている。
Decathlon社は世界的な小売企業であり、顧客向けのeコマースプラットフォームと多くのバックオフィスシステムを組み合わせた大規模な技術プラットフォームを有している。多くのWebおよびモバイルフロントエンドアプリケーションを抱える同社は、マイクロサービスベースのバックエンドアーキテクチャの上で、さまざまなユーザーエクスペリエンスのニーズをサポートするための支援を必要としていた。
これらの課題に対応して、同社はBackend For Frontend (BFF)パターンを導入した。このパターンでは、フロントエンド チームがバックエンド・ミドルウェア・サービスを所有および管理し、そのニーズのサポートに特化したオーケストレーションと集約を処理する。この新しい抽象化レイヤーは、システム・コンポーネント間の結合を減らすことで、懸念事項の分離と柔軟性の向上を可能にする。
/filters:no_upscale()/news/2024/03/decathlon-backend-for-frontend/en/resources/1decathlon-bff-arch-1710071891347.jpeg)
Backend For Frontendパターン（出典：Decathlon Digital Blog）
BFFレイヤーは、データ操作／適応（APIデータだけでなく、例えば画像のリサイズなど）、プロトコルの柔軟性（WebSocket、GraphQLなど）、セキュリティ（認証）、サーバーサイドレンダリング(SSR)のサポートなど、多くの考慮事項に対応できる。BFFを導入することで、FEチームはデータフェッチ、非正規化、集計ロジックをFEアプリに押し込むことを避けることができ、フロントエンドのスパゲッティコード、コードとデータのためのネットワーク使用量、JavaScriptバンドルサイズ、ブラウザで使用されるコンピュートリソースのリスクを減らすことができる。
BFFパターンに課題がないわけではなく、Decathlon社のエンジニアは、新しいレイヤーがプラットフォーム全体の品質に悪影響を及ぼさないようにするための戦略を考案した。間違いなく最大のリスクは、BFF間でビジネスロジックが矛盾して重複したり、コールスタックの下位で管理されるべきビジネスロジックを実装したりすることに起因する。 Decathlon社では、このような懸念事項を定期的に議論する目的でアーキテクチャ委員会を設立し、ADRを使用して、結果として生じるアーキテクチャ上の意思決定(AD)を把握することを求めている。
/filters:no_upscale()/news/2024/03/decathlon-backend-for-frontend/en/resources/1decathlon-bff-graceful-degradation-1710071891346.jpeg)
フォールトトレランスとグレースフルデグラデーション（出典：Decathlon Digital Blog）
BFFサービスがエラーを優雅に処理し、不安定な場合にダウンストリームのサービスに負担をかけないようにするためのフォールトトレランスが、注意を要する2つ目の主要分野だ。チームは、サーキットブレーカーと隔壁のパターンを推進し、ダウンストリーム・サービスの障害に対応し、隔離する。障害が発生した場合、潜在的に古い、キャッシュされたデータ、またはデータがフロントエンド・アプリケーションに返されず、ユーザー・エクスペリエンスを優雅にダウングレードする方法が提供される。
シリーズの最後のパートでは、BFFに代わる方法として、OTA（Over-the-Air Deployments）、HALを使用したHATEOAS、サーバー駆動型UI (SDUI)について、それぞれの長所と短所、さまざまなタイプのFEアプリケーションや組織の規模に適合するレベルについて説明する。
InfoQは、Decathlon社のスタッフエンジニアであるRaphaël Tahar氏に、同社がBFFパターンを使用した経験についてインタビューした。
InfoQ: BFFパターンを使った Decathlon社の経験を大まかにまとめてもらえるだろうか。組織全体にBFFを展開する上で、もっとも困難な要素や側面は何だったのか？
Raphaël Tahar氏
困難な制約は、組織全体（何千ものプロジェクト）に広がる多種多様な機能的・技術的ユースケースを考慮して標準を構築することでした。
社内ユーザーが使うものもあれば、顧客が使うものもある。
あるエクスペリエンスはブラウザで消費され、あるエクスペリエンスはモバイルやコネクテッドデバイスで消費される。
技術の組み合わせの複雑さがまちまちである（技術レーダーには、4つ以上の言語にわたる〜10のフレームワークが含まれている）
チームトポロジー（人員配置とハードスキル）の違い
BFFは銀の弾丸ではないので、プラグマティズムは必須であり、正確なデシジョンツリーを構築できましたが、それは簡単なことではありませんでした。
InfoQ: 多くの組織がオーケストレーション/アグリゲーションにGraphQLを採用している。BFFsの代替としてGraphQLを採用した理由を教えてほしい。
Tahar氏:
私にとってGraphQLは、それ自体のアーキテクチャパターンというよりも、むしろ「クエリ言語 - プロトコル」です。GraphQLはヘルメットのようなもので、既存のサービスの上位に位置し、関連するデータを簡単に選択できるようにしてくれます。だから、BFFパターンに追加するには最適ですが、この2つのコンセプトが競合しているとは 言いません。
BFFのポイントは、フロントエンドチームがアプリケーションに提供するAPIを所有することであり、GraphQLはペイロード、エンドポイント、トラフィックのラウンドトリップを最適化することです。つまり、BFFとGraphQLは関連していますが、相互に排他的ではありません。
一方、GraphQLフェデレーションはBFFの本格的な代替になるかもしれませんが、そのようなアーキテクチャを実装するのは、特に大規模な組織では容易ではありません。
InfoQ: マイクロ・フロントエンド・アーキテクチャ（MFA）は、業界でトレンドとなっているもう1つのアイデアだ。Decathlon社はその採用を検討しているのか？
Tahar氏
Decathlon社は何年も前からビルドとランタイムのMFAを使っています。例えば、Web ComponentsはWeb標準の純度と安定性の恩恵を受けるために使用されていますが、いくつかの制限がグローバルな採用を妨げていました。そこで、そのギャップを埋めるために他の技術が使われています（例えば、single-spaのフレームワーク）。