React Server Components: Data Loading Patterns in Next.js

What and Why

React Server Components (RSC) let components run on the server, await data inline, and stream HTML to the browser without shipping their JavaScript. In the Next.js App Router, every component under app/ is a Server Component by default. This collapses the old split between “page data fetching” and “component rendering” — a component is now just an async function that can await anything.

The win is twofold: less JavaScript reaches the client (smaller bundles, faster TTI) and data sits next to the UI that uses it (no prop drilling from a top-level getServerSideProps).

Mental Model

A Server Component is a function the server renders into a serializable description of UI. It can read databases, call internal services, and use secrets — none of that crosses the network. When it embeds a Client Component, Next.js inserts a placeholder and ships the Client Component’s JS so the browser can hydrate that subtree interactively.

fetch is patched. Two identical fetch(url) calls in the same render are deduplicated automatically, so colocating data fetching in leaf components is cheap. Caching is opt-out via cache: 'no-store' or next: { revalidate: N }.

Hands-on Example

Consider a product page that needs the product, related items, and the current user’s wishlist status. Instead of one big top-level fetch, each section fetches what it needs.

// app/products/[id]/page.tsx
import { Suspense } from 'react';
import { getProduct } from '@/lib/products';
import Related from './Related';
import WishlistButton from './WishlistButton';

export default async function ProductPage({ params }) {
  const product = await getProduct(params.id);
  return (
    <main>
      <h1>{product.name}</h1>
      <WishlistButton productId={product.id} />
      <Suspense fallback={<p>Loading related…</p>}>
        <Related categoryId={product.categoryId} />
      </Suspense>
    </main>
  );
}

Related is its own async server component that fetches slower data. Wrapping it in Suspense lets Next.js stream the main product immediately and flush related items when ready.

Request /products/42
 |
 v
[Server] render ProductPage (async)
 |-- await getProduct(42)        [fast: 30ms]
 |-- flush shell HTML to client  ---------> browser paints header
 |
 |-- Suspense boundary for Related
 |    await getRelated(...)      [slow: 400ms]
 |    flush chunk                ---------> browser swaps fallback
 |
 v
[Done]  full HTML streamed; no client refetch needed

WishlistButton is a Client Component (it has 'use client' at the top) because it needs onClick and local state. The server renders its initial markup; the client takes over for interaction.

For data that varies per user, mark the fetch dynamic:

const res = await fetch(`${API}/wishlist`, { cache: 'no-store' });

Or use the cookies() / headers() helpers, which automatically opt the route into dynamic rendering.

Common Pitfalls

The biggest pitfall is accidentally turning everything into a Client Component. The moment a parent has 'use client', every imported child is a Client Component too, even if it has no interactivity. Push 'use client' as far down the tree as possible — typically to the leaf that actually uses state or browser APIs.

Second, leaking secrets through props. If a Server Component fetches an API key and passes it to a Client Component as a prop, it serializes into the page payload and ships to the browser. Only pass the result of a server call, not the credentials.

Third, N+1 fetches. Request memoization helps for identical fetches, but a loop calling getUser(id) for 100 different IDs still makes 100 round-trips. Batch with a single query or use a DataLoader-style helper.

Fourth, forgetting that fetch is cached by default. A POST-like call without cache: 'no-store' may be served from cache, returning stale data. Always tag mutations clearly.

Best Practices

Treat Server Components as the default and add 'use client' only when you need state, effects, or event handlers. Colocate data fetching next to the UI that consumes it — the deduplication makes this safe. Use Suspense boundaries to isolate slow data and let the fast parts render immediately. For per-user content, prefer revalidateTag over cache: 'no-store' so most users hit the cache and only mutations bust it. Keep server-only modules behind the server-only package so an accidental client import fails the build instead of leaking at runtime.

Wrap-up

RSC reframes data loading as just await inside a component. With request deduplication, streaming Suspense, and a clear server/client boundary, you get faster pages and simpler code than the old getServerSideProps world — provided you respect where the boundary lives and what each side can safely see.