BFF UIホスティング戦略
Backend For Frontend (BFF) パターンを使用したモダンなWebアプリケーションを構築する際、UIアセットの適切なホスティング戦略を選択することは、パフォーマンスの最適化、デプロイの簡素化、そしてBFFシステムとのシームレスな統合を確保するために重要です。
UIホスティングのオプション
BFFを使用する場合、UIアセットをホストするための3つの主要なオプションがあります。
1. BFFホストからSPAアセットを提供
概要
UIをBFFと一緒にホスティングすることは最もシンプルな選択肢です。フロントエンドからバックエンドへのリクエストには自動的に認証Cookieが含まれ、CORSヘッダーも不要です。これにより、BFFとフロントエンドアプリケーションが単一のデプロイ可能なユニットになります。
実装方法
Duendeのテンプレートを使用してBFFホストを作成すると、UIはこの方法でホスティングされます：
dotnet new duende-bff-remoteapi
# または
dotnet new duende-bff-localapi
開発時の考慮事項
多くのフロントエンドアプリケーションはビルドプロセスを必要とするため、開発時の静的ファイルミドルウェアの使用が複雑になります。Visual Studioには、開発中にSPAを起動してリクエストをプロキシするSPAテンプレートが含まれています。
Duende.BFFのサンプルは、以下のフレームワークでこのアプローチを採用しています：
Microsoftのテンプレートは、Visual Studioからの開発時に使いやすいです。ソリューションを実行すると、テンプレートがフロントエンドへのリクエストをプロキシします。デプロイ時には、このプロキシが削除され、サイトの静的アセットは静的ファイルミドルウェアによって提供されます。
メリット
- 最もシンプルな構成
- 認証Cookieの自動送信
- CORS設定が不要
- 単一のデプロイユニット
デメリット
- フロントエンドとバックエンドの個別デプロイができない
- CDNの利用が困難
2. UIを個別にホスト
概要
UIをBFFの外部にホストすることもできます。開発時には、UI開発者がVisual Studioの外部（例：Node CLIを使用）でフロントエンドを実行することを好む場合があります。また、フロントエンドとBFFを個別にデプロイしたい場合や、静的UIアセットをCDNでホストしたい場合にも有用です。
ブラウザはBFF経由でアプリケーションにアクセスします。BFFはindex.htmlへの呼び出しをCDNにプロキシします。ブラウザはCDNからすべての静的アセットをダウンロードできますが、BFF（およびそのAPIとユーザー管理API）を認証Cookieで保護された状態で通常どおり使用します。
実装要件
このアーキテクチャを機能させるには、以下が必要です：
-
キャッチオールルーティング
- クライアントサイドルーティングを機能させるために、index.htmlへの呼び出しをプロキシするキャッチオールルートを設定する必要があります
- index.htmlが提供されると、フロントエンドがアプリケーション固有のルーティングを引き継ぎます
-
API除外設定
- BFFがホストするAPIとアプリケーションのAPIは、このキャッチオールルーティングから除外する必要があります
- ただし、ブラウザが直接アクセスすべきではありません
-
CORS設定
- CDNは、アプリケーションのオリジンからのCORSリクエストを許可するように設定する必要があります
-
認証Cookie送信
- フロントエンドコードは、認証Cookieを含めるために
credentials: "include"オプションを使用する必要があります
- フロントエンドコードは、認証Cookieを含めるために
// Fetch APIでの認証Cookie送信例
fetch('https://bff.example.com/api/data', {
credentials: 'include'
})
- サブドメイン構成
- フロントエンドとBFFホストは、サードパーティCookieブロッキングを回避するため、同じドメインのサブドメインでホストする必要があります
メリット
- フロントエンドとバックエンドの個別デプロイが可能
- CDNの活用による静的アセット配信の最適化
- 開発者の作業環境の柔軟性
デメリット
- CORS設定が必要
- サブドメイン構成の要件
- 設定の複雑性が増す
サンプル実装が利用可能です。
3. BFFホストからインデックスページのみを提供
概要
最後のオプションは、SPAのインデックスページをBFFから提供し、その他すべての静的アセットを別のホスト（おそらくCDN）でホストする方法です。このテクニックにより、UIとBFFはまったく同じオリジンを持つため、認証CookieはフロントエンドからBFFに自動的に送信され、サードパーティCookieブロッキングやSameSite Cookie属性の問題は発生しません。
実装の課題
ローカル開発でこれを設定するには、少し努力が必要です：
-
インデックスページの同期
- フロントエンドに変更を加えると、UIのビルドプロセスがインデックスページに変更を生成する可能性があります
- その場合、BFFホストが提供するインデックスページにその変更を反映させる必要があります
-
アセットパスの設定
- フロントエンドは、他のホストからアセットをロードできるように設定可能である必要があります
- そのメカニズムは、フロントエンドの構築に使用される技術によって異なります
- 例：Angularには、アセットの場所を制御できる多数のデプロイオプションが含まれています
BFF V4のサポート
BFF V4には、CDNからindex.htmlをプロキシするための組み込みサポートがあります。
メリット
- 認証Cookieの自動送信（同一オリジン）
- サードパーティCookieブロッキングの問題なし
- CDNによる静的アセット配信の最適化
デメリット
- ローカル開発の設定が複雑
- インデックスページの同期管理が必要
- フロントエンドの設定可能性が必要
この技術の追加の複雑性は、BFFとは異なるサイト（通常はCDN）でフロントエンドをホストする必要がある場合に正当化されます。
選択のガイドライン
| ホスティング方法 | 推奨ケース | 複雑性 |
|---|---|---|
| BFFホストから提供 | 小〜中規模アプリ、シンプルな構成を優先 | 低 |
| 個別ホスト | 個別デプロイが必要、開発チームが分離 | 中 |
| インデックスのみBFF | CDN利用が必須、セキュリティ最優先 | 高 |
セキュリティの考慮事項
- すべてのオプションで、HTTPS通信を使用する必要があります
- 認証Cookieには適切な属性（HttpOnly、Secure、SameSite）を設定する必要があります
- CORSを使用する場合は、許可するオリジンを厳密に制限する必要があります
- サードパーティCookieブロッキングの影響を理解し、適切に対処する必要があります
まとめ
適切なUIホスティング戦略の選択は、アプリケーションの要件、チーム構成、デプロイ戦略に依存します。最もシンプルなアプローチから始めて、必要に応じてより複雑な構成に移行することを推奨します。