アンダーフェッチは、1回のAPI呼び出しでは足りず、必要な情報をそろえるのに何回も呼ぶ必要がある状態です。
初心者向けには、一覧APIを叩いた後、1件ずつ詳細APIを叩き、さらに関連APIも叩く 状態と考えるとつかみやすいです。
どんな場面で起きるか
何が問題になるか
問題の本体は通信量ではなく往復の回数です。 1往復あたりの遅延が100ミリ秒なら、直列で5往復すればそれだけで0.5秒かかります。モバイル回線や海外からのアクセスでは、この遅延が支配的になります。
- 画面表示までの体感が遅くなる
- リクエスト数が増え、レート制限やサーバー負荷にも効く
- エラー処理が分岐だらけになり、実装が壊れやすくなる
対処の方向
- GraphQL で、必要な関連データをまとめて1回で取得する
- REST API でも
?include=department,ordersのような埋め込みや、画面用の集約エンドポイントを用意する - 画面ごとに必要な形へ整えて返す層（BFF）を挟む
- 直列にせず、独立したリクエストは並列で投げる（これだけで体感が変わることも多い）
近い問題との違い
- オーバーフェッチ … 取りすぎる問題。アンダーフェッチとは逆向きで、片方を潰すともう片方が出やすい
- N+1問題 … 似ているが層が違います。N+1は主にアプリとデータベースの間で1件ずつクエリが飛ぶ話、アンダーフェッチはクライアントとサーバーの間で往復が増える話です。GraphQL でアンダーフェッチを解消しても、サーバー側で N+1 が残ることはよくあります
実務での見方
まずブラウザの開発者ツールのネットワークタブで、1画面あたり何往復しているかを数えるのが早いです。
直列で3往復以上 が常態化しているなら、集約する価値があります。逆に往復が1〜2回なら、無理にAPIを作り替える必要はありません。
あわせて見たい用語
方式ごとの向き不向きは GraphQLとREST APIの違いは？ で整理しています。