アーキテクチャ全体像と BFF の位置

1章で示したブラウザ・BFF・バックエンド API の構成図（再掲）

docker compose up

$ cd ch02-bff-basics$ docker compose up -d

起動する 3 つのコンテナ

docker compose up で起動する 3 つのコンテナ

Web 版とモバイル版の表示情報

モバイル版と Web 版の商品詳細画面の情報量の違い

注記: ここから先の演習は「もし BFF がなかったら？」という仮定で進める（BFF コンテナは起動済みだが、しばらく使わない）

バックエンド API が返すデータの性質

over-fetching と under-fetching

1 つの API を共有する 2 つのクライアントに起きるトレードオフ

バックエンド APIを直接呼び出す構成

BFF なしでクライアントがバックエンド APIを直接叩く構成

モバイル版画面と over-fetching

モバイル版の商品詳細画面（再掲）と、レスポンス 12 フィールドのうち使うのは 3 つだけであることの対比

何が over か — 画面が使うのは name・price・images の 3 フィールドだけなのに、description、specs、stock、warehouseCode など残りの 9 フィールドも毎回受け取っている

Web 版画面と under-fetching

Web 版の商品詳細画面（再掲）と、1 画面の表示に 2 回のリクエストが必要であることの対比

何が under か — 商品サービスへの 1 回のリクエストでは画面に必要なデータが揃わず、レビューサービスへの追加リクエストが必要になる

さらに変換処理も残る — 在庫数 142 を「在庫あり」へ、価格 15800 を「¥15,800」へ変換する処理をクライアント側で実装しなければならない

BFF がバックエンド API を集約・整形する

BFF が 2 つのバックエンド APIを束ねて 1 つのレスポンスを返す構成

BFF の定義

BFF を含む 3 つのコンテナ

BFF・商品サービス・レビューサービスの 3 コンテナが起動した状態

直接呼び出しと BFF 経由の比較

BFF アプリケーションの構成

BFF のルートハンドラ

Promise.all による並行呼び出し

const [product, reviews] = await Promise.all([  fetch(`${PRODUCT_SERVICE}/api/products/${id}`).then((r) => r.json()),  fetch(`${REVIEW_SERVICE}/api/products/${id}/reviews`).then((r) => r.json()),]);

表示用データへの変換

表示用データの変換例

price: `¥${product.price.toLocaleString()}`,stockStatus: product.stock > 0 ? "在庫あり" : "在庫なし",

この章のまとめ