Skip to main content

RSC After Six Months: What Surprised Me Most

2 min read
react javascript architecture

The mental model shift

After six months building with React Server Components (RSC), the biggest shift isn’t technical — it’s architectural. You stop thinking “what runs on the server vs client” and start thinking “what needs interactivity?”

What surprised me

1. Direct database queries in components feel weird — then liberating.

// This runs on the server. No API route needed.
async function PostList() {
  const posts = await db.query(`SELECT * FROM posts ORDER BY date DESC`);
  return <PostListClient posts={posts} />;
}

No useEffect, no fetch, no loading states for the initial data. Just await and render.

2. The “use client” boundary is infectious.

Once a component uses hooks, event handlers, or browser APIs, everything under it also needs client components. I’ve learned to push the boundary as low as possible — keep server components at the page and layout level.

3. Streaming changes the loading UX.

With Suspense boundaries and streaming, you get a progressively filled page without extra client code. The old pattern of “show skeleton → fetch → replace” becomes “stream as ready.”

What I learned

RSC isn’t faster by default. The win comes from eliminating waterfalls: data that the server already has never needs a round-trip. If your biggest pain point is client-side data fetching waterfalls, RSC will feel transformative. If it’s client-side interactivity, it’ll feel incremental.