Web Dev
React Server Components: When and How to Use Them in Next.js
November 202510 min read
Web Dev
React Server Components (RSC) are the most significant shift in React's programming model since hooks. In Next.js 15 with the App Router, every component is a Server Component by default. Zero JavaScript for pure render components, no hydration, and direct database access without an API layer. But they're not a replacement for Client Components — they're a complement. After building several App Router applications from the ground up, here's my practical understanding of how to use them effectively.
The fundamental change: Server Components run only on the server and send HTML (not JavaScript) to the client. A Server Component that fetches from Prisma never ships the Prisma client, the database query logic, or any associated code to the browser. The client receives rendered HTML. This eliminates an entire category of data fetching — no useEffect, no loading states for initial data, no client-side fetch. The component is already rendered with data when it reaches the browser.
The 'use client' directive doesn't make the component server-less — it marks a boundary where the component tree becomes client-rendered. Everything above the boundary can be a Server Component. The most common mistake: marking a parent component 'use client' when only one leaf component needs interactivity. You can pass Server Component output as props (children) into a Client Component — the Server Component renders on the server, its output (HTML) is passed as children prop to the client-rendered wrapper.
Server Components (default) Client Components ('use client')
─────────────────────────── ─────────────────────────────────
✅ Direct database access ✅ useState, useEffect
✅ Async/await at component level ✅ Event handlers (onClick, onChange)
✅ 0 JS shipped to browser ✅ Browser APIs (window, localStorage)
✅ Server secrets (env vars) ✅ Real-time subscriptions
✅ Reduced client bundle ✅ Drag-and-drop
✅ Charts (DOM-dependent)
Server
┌─────────────────────────────────────────┐
│ page.tsx (Server Component) │
│ await prisma.user.findMany() ─── DB │
│ │ │
│ ▼ │
│ <UserList users={users}> │
│ └─ Server Component (renders HTML) │
│ │ │
│ <DataTable data={users}> ◄── 'use client'
│ └─ Client Component: sorting/filtering│
└─────────────────────────────────────────┘
HTML streamed to browser
─────────────────────────────────────────
Prisma client: never shipped to browser ✅
DataTable JS: shipped for interactivity ✅From building an ERP dashboard with Next.js App Router: fetch data at the highest Server Component level possible, then pass it down as props to the interactive Client Components below. The Server Component runs the Prisma query, passes the result as a prop to a 'use client' DataTable component. The DataTable can do client-side sorting, filtering, and pagination without ever hitting the API again — all data is already there from the initial server render.
Async/await in Server Components is the clean default. A Server Component can be async — await a Prisma query, await fetch() to an external API, await Redis.get() — and render the result directly. Multiple independent data fetches in a component should use Promise.all() to parallelize rather than waiting sequentially. Dependent data (fetch B only after A returns) can use sequential await, but consider whether Suspense streaming would serve the user better — render what you have, stream the rest.
// ✅ Server Component with parallel data fetching
export default async function Dashboard() {
// These run in parallel (not waterfall)
const [users, orders, revenue] = await Promise.all([
prisma.user.count(),
prisma.order.findMany({ where: { status: 'PENDING' } }),
prisma.order.aggregate({ _sum: { total: true } }),
])
return (
<div>
<StatsCard users={users} revenue={revenue._sum.total} />
{/* Server Component passes data to Client Component */}
<OrdersTable orders={orders} /> {/* 'use client' inside */}
</div>
)
}
// ✅ Streaming with Suspense
export default function Page() {
return (
<div>
<QuickStats /> {/* Fast — renders immediately */}
<Suspense fallback={<TableSkeleton />}>
<SlowDataTable /> {/* Slow — streams when ready */}
</Suspense>
</div>
)
}
// ✅ Caching Prisma queries with unstable_cache
import { unstable_cache } from "next/cache"
const getProducts = unstable_cache(
async () => prisma.product.findMany(),
["products"], // cache key
{ revalidate: 3600 } // revalidate every hour
)
// ❌ Anti-pattern: fetching in Client Component unnecessarily
"use client"
export function UserProfile({ userId }) {
const [user, setUser] = useState(null)
useEffect(() => {
fetch(`/api/users/${userId}`).then(r => r.json()).then(setUser)
}, [userId])
// ↑ Doubles latency: server renders, HTML arrives, hydrates, then fetches again
// Fix: pass user as prop from Server Component parent
}Suspense boundaries let you progressively stream Server Component output. Wrap a slow-loading Server Component in <Suspense fallback={<Skeleton />}> and Next.js streams the page: the fast parts render immediately, the slow parts render when ready, replacing the skeleton. This improves perceived performance significantly — users see content rather than a blank screen. The loading.tsx file in App Router is syntactic sugar for a Suspense boundary around the page component.
A common anti-pattern: a Server Component renders a Client Component, which then uses useEffect to fetch the same data the Server Component could have provided. This doubles the latency — the server renders, the HTML arrives, the JS hydrates, and then the client fires another fetch. Always fetch in the Server Component and pass as props. The Client Component should handle interactivity only — mutations, user events, real-time updates via WebSocket. Initial data comes from the server.
Next.js's fetch() in Server Components has automatic caching. By default, responses are cached per request (deduplication within a request). You control longer caching with { next: { revalidate: N } } (ISR-style time-based revalidation) or { cache: 'no-store' } for always-fresh data. Prisma queries don't go through fetch(), so they're not auto-cached — use Next.js's unstable_cache() wrapper to apply caching to Prisma queries, Redis calls, or any async function you want to cache across requests.
My rule: everything that doesn't need useState, useEffect, event handlers, or browser APIs is a Server Component. The list of things that need Client Components is shorter than you'd expect: form controls with controlled state, modals and drawers with open/close state, charts (they access the DOM), drag-and-drop interactions, and real-time subscriptions. My RSC-heavy ERP dashboards load significantly faster than the previous Pages Router version — the JavaScript bundle is 40-50% smaller and there's no waterfall from client-side data fetching.
Server Components are excellent for SEO because the content is in the initial HTML response — no JavaScript required for search engines to see it. Product pages, blog posts, and marketing pages benefit most. The Next.js metadata API (generateMetadata, the metadata object export) also works at the Server Component level — dynamic OG images, canonical URLs, and structured data are all rendered server-side. This is the proper SEO-first architecture for any public-facing web application.