Server Component fetch vs. client-side SWR or React Query

WHAT THIS TESTS: This question evaluates whether you can reason about the App Router's streaming architecture and make deliberate cache and boundary decisions. Interviewers want to see that you understand request waterfalls, bundle size trade-offs, and when user interactivity demands client-side state.

A GOOD ANSWER COVERS: First, initial page load and TTFB. Server Components fetch during render on the server, so the browser receives markup or data without a client-side round trip. This eliminates the fetch-then-render waterfall and removes data fetching code from the JavaScript bundle entirely. Second, caching granularity. Next.js extends the Web fetch API so identical requests are automatically deduplicated across the server render tree, and results can be cached at the edge or reused across requests. Client libraries like SWR and React Query provide stale-while-revalidate, background refetching on focus, and optimistic mutations, which are superior for highly interactive or rapidly changing data. Third, complexity and bundle cost. Moving fetch logic to the server shrinks the client bundle, often by 10 to 15 kilobytes gzipped when you remove a client fetching library, but it forces you to handle user-specific or mutable data through server actions or separate client islands. Fourth, the hybrid pattern. The best architectures use Server Components for stable, SEO-critical, or layout-level data, and reserve Client Components with React Query or SWR for user dashboards, real-time feeds, and mutation-heavy UIs.

COMMON WRONG ANSWERS: A major red flag is defaulting to client fetching for every data need without considering the hydration and waterfall penalties. Another is claiming Server Components can only serve static data; they fully support dynamic, request-specific fetches. Candidates who dismiss server caching because they are used to React Query's client cache also signal shallow understanding.

LIKELY FOLLOW-UPS: How would you structure a page that mixes public marketing content with private real-time notifications? When does prefetching with React Query on the server make sense compared to a native Server Component fetch? How do you prevent request waterfalls when multiple Server Components need related but separate data?

ONE CONCRETE EXAMPLE: Imagine an e-commerce product page. The product description, review summary, and SEO metadata should be fetched directly in a Server Component so the edge can cache the response and the client downloads no fetching logic for that section. The inventory check for Add to Cart and a Recently Viewed carousel should live in Client Components using React Query to enable optimistic updates, background refetching, and instant mutation feedback without a full server round trip.