一覧データの取得はどこに書きますか。
page.tsx を async にして、その中で直接 await します。ブラウザとAPIの往復が1回減り、取得用のコードとキーがクライアントに送られず、ローディング状態の管理も減ります。
面接官が見ているのはServer Component でのデータ取得が基本形だと理解しているか。
よくある答えと、面談でどう見られるか
- Server Component を async にして、その中で直接 await する
これが基本形です。往復が減り、秘密情報もクライアントに出ません。 - Client Component の useEffect の中で fetch する
動きますが、App Router でこれを既定にする理由は薄いです。表示までにブラウザ→APIの往復が1回増えますし、loading と error の状態を自前で持つことになります。面談では「なぜサーバーで取らないのか」を必ず聞かれます。 - Route Handler を作って、そこから取得する
外部に口が要るなら妥当ですが、自分の画面に出すだけなら遠回りです。Server Component から直接呼べるものを、わざわざHTTP越しにしていることになります。 - proxy（旧 middleware）で取得して、リクエストに載せる
全リクエストが通る場所なので、ここにデータ取得を置くと全ページが遅くなります。置くのは軽い判定だけにします。
面接官は何を見ているか
- Server Component の中で直接 await する形を挙げた
- useEffect でクライアントから取りに行く形との違いを説明できた
- 認証情報やDBに直接触れる利点に触れた
模範解答
基本は Server Component の中で直接 await します。page.tsx を async にして、その中で fetch なり ORM なりを呼ぶ形です。
useEffect でクライアントから取りに行く形と比べた利点は3つあります。表示までにブラウザ→APIの往復が1回減ること、APIキーやDB接続情報がクライアントに出ないこと、データ取得用の状態管理（loading / error のフラグ）を自前で持たなくて済むことです。
Server Component はサーバーでレンダリングされるので、ORM やDBクライアントを直接呼んでも、そのコードはクライアントバンドルに入りません。
ここからどう深掘りされるか
この問いに答えられた場合、面談は次の質問に進みます。
観点をすべて押さえられた場合
その fetch の結果はキャッシュされますか。一部しか触れられなかった場合
Server Component の中で useEffect を使ってデータを取ることはできますか。