React 19 Server Components in Production

React Server Components landed in production React 19 and Next.js App Router after years in canary. The promise — zero-bundle server rendering with full access to server resources — is real. So are the footguns.

The Mental Model Shift

The critical change: React now has two execution environments running the same component tree. Server Components run once on the server (or at build time), never re-render, and cannot hold state. Client Components run on the client and can do everything you already know.

// server-component.tsx (no "use client" — server by default in App Router)
import { db } from '@/lib/db'; // direct DB access — no API round-trip

export async function ArticleList() {
  const articles = await db.article.findMany({ orderBy: { date: 'desc' } });
  return (
    <ul>
      {articles.map(a => <li key={a.slug}>{a.title}</li>)}
    </ul>
  );
}

// like-button.tsx
'use client';
import { useState } from 'react';

export function LikeButton({ initialCount }: { initialCount: number }) {
  const [count, setCount] = useState(initialCount);
  return <button onClick={() => setCount(c => c + 1)}>{count} likes</button>;
}

The composition rule: Server Components can render Client Components, but Client Components cannot import Server Components — they can only receive them as children props.

Passing Server Data to Client Components

The correct pattern for interactive islands inside server-rendered trees:

// page.tsx (Server Component)
import { ArticleContent } from './ArticleContent'; // Server
import { CommentThread } from './CommentThread';   // Client

export default async function ArticlePage({ params }: { params: { slug: string } }) {
  const [article, comments] = await Promise.all([
    fetchArticle(params.slug),
    fetchComments(params.slug),
  ]);

  return (
    <article>
      <ArticleContent article={article} />
      {/* Pass serializable data — no functions, no class instances */}
      <CommentThread initialComments={comments} articleSlug={params.slug} />
    </article>
  );
}

The constraint on serializable props is real and enforced at runtime. Passing a Date object through an RSC boundary will throw — pass ISO strings and rehydrate on the client.

Caching Is Not Optional

Server Components run per-request by default. Without caching, a page with 5 data fetches will hit your database 5 times on every request.

// Use React's cache() for per-request deduplication
import { cache } from 'react';

export const getUser = cache(async (id: string) => {
  return db.user.findUnique({ where: { id } });
});

For cross-request caching, Next.js extends fetch with revalidation options:

const data = await fetch('/api/products', {
  next: { revalidate: 3600 } // stale-while-revalidate: 1 hour
});

Common Pitfalls

Context across the boundary: React Context does not work in Server Components. Extract client-only state into 'use client' providers; pass static config through props or import.

Async Client Components: React 19 supports use(promise) in Client Components but this is not the same as async/await. Keep async data fetching in Server Components.

Large serialized payloads: Every prop crossing the RSC boundary becomes JSON in the HTML payload. Fetching full rich-text article bodies server-side and passing them to a client editor will bloat the page. Fetch minimally; fetch rich data client-side when needed for interactivity.

Third-party libraries: Many libraries assume a browser environment. Wrap them in dynamic imports with ssr: false or ensure they have proper 'use client' directives.

When Not to Use Server Components

Server Components add complexity. For admin dashboards, highly interactive tools, or forms with optimistic updates — Client Components remain the right choice. The wins are real for content-heavy pages, data tables, and authenticated layouts where you want to eliminate client-side data fetching entirely.

Measure before converting. The bundle reduction is real; the complexity cost is also real.