Last year we took over a Next.js dashboard for a logistics client that was shipping 640KB of client JavaScript just to render a table of shipments. Half of that was data-fetching glue: a useEffect that fired on mount, a loading spinner, a second useEffect for pagination, and three different libraries fighting over cache invalidation. We rewrote the whole data layer around React Server Components in about two weeks, and the client bundle dropped by 40%. That's the number that gets people's attention, but it's not actually the interesting part.

The interesting part is that we stopped thinking about data fetching as a frontend problem at all.

The mental model shift nobody warns you about

If you've built React apps for a while, you have a deeply ingrained habit: component renders, component fetches, component re-renders with data. Server Components break that loop entirely. A server component runs once, on the server, and it's done. There's no re-render because there's no client-side lifecycle to speak of. The first time you write await fetch(...) directly inside a component body with no useEffect, no loading state, and no error boundary gymnastics, it feels wrong. It felt wrong to us too, for about a week.

Once it clicks, though, you realize how much of your old "frontend" code was actually backend code wearing a React costume. Data transformation, authorization checks, database queries dressed up as API calls to your own backend — all of that can now live where it always should have: on the server, close to the data.

What we actually deleted

On that dashboard rewrite, here's what disappeared entirely:

Three custom React Query hooks that existed only to wrap our own internal API
A loading skeleton component used in 14 places
An entire Redux slice dedicated to caching shipment data client-side
Two API routes that existed purely to reshape database results for the frontend

That last one matters more than it sounds. When your server component can query the database (or call an internal service) directly, you don't need a REST endpoint whose entire job is proxying data from one internal system to your React tree. We had routes that took a Postgres row, renamed four fields, and sent it back as JSON. Pointless, once the component doing the rendering lives on the server too.

Where it gets messy: client boundaries

The part that took us longest to get right wasn't the server components themselves — it was figuring out where the client boundary should sit. Every interactive element (a filter dropdown, a sortable column header, a modal) needs the "use client" directive somewhere upstream, and it's tempting to slap it on a huge chunk of your tree just to make the TypeScript errors go away.

Don't do that. We made this mistake in week one: a `ShipmentsTable` component needed one sortable header, so we marked the whole table `"use client"`, which meant every row's server-fetched data now had to be serialized and shipped across the boundary as props. That's the exact bundle bloat we were trying to eliminate, just moved one layer down.

// Wrong: whole table becomes client, data gets serialized as props
"use client";
export function ShipmentsTable({ shipments }) {
  return shipments.map(row => <Row key={row.id} {...row} />);
}

// Better: server component stays server, only the interactive header is client
export async function ShipmentsTable() {
  const shipments = await getShipments();
  return (
    <table>
      <SortableHeader /> {/* "use client", tiny, no data passed */}
      {shipments.map(row => <Row key={row.id} row={row} />)}
    </table>
  );
}

The rule we landed on: push client boundaries as far down the tree as physically possible, and never pass more props across that boundary than the interactive element strictly needs. It sounds obvious written down. It is not obvious when you're three levels deep in a component tree at 6pm trying to make a build pass.

Caching is still the hard part

Server Components don't magically solve caching, they just relocate the problem. We got burned once by Next.js's aggressive fetch caching serving stale shipment statuses to a customer who'd just paid for expedited shipping — the kind of bug that generates a support ticket within minutes. The fix was explicit: tag every fetch with cache: "no-store" or a short revalidate window for anything that changes on a human timescale, and reserve the default caching behavior for data that's genuinely static, like a shipment's origin address.

If there's one piece of advice I'd give a team starting this migration: don't trust the framework defaults for anything a customer would notice was wrong. Be explicit about staleness on every fetch that touches money, status, or inventory.

Was it worth it

For that dashboard, yes, clearly. Bundle size dropped, time-to-interactive on 3G went from just under 5 seconds to about 2.1, and we deleted more code than we wrote. But I wouldn't tell every team to rush into this. If your app is mostly static marketing pages, you're solving a problem you don't have. Server Components pay off when you have genuinely data-heavy screens where the old client-fetch waterfall was the actual bottleneck. Know which kind of app you're building before you tear out a working data layer to chase an architecture trend.