The Architecture Shift: Why Server Components Exist
React Server Components (RSC) represent the biggest architectural change since React Hooks. The core idea: components that run exclusively on the server, sending only their rendered output (not their JavaScript) to the client. This means zero bundle size for server components.
Before RSC, React had two rendering strategies: Client-Side Rendering (CSR) where everything runs in the browser, and Server-Side Rendering (SSR) where HTML is generated on the server but the full component JavaScript is still sent to the client for "hydration". RSC introduces a third option: components that never ship any JS to the client at all.
This is not just a performance optimization — it fundamentally changes how you think about data fetching, security, and bundle management. Server Components can directly access databases, file systems, and internal APIs without exposing them to the client.
Key Takeaways
Server vs Client Components: The Decision Framework
In Next.js 15, every component is a Server Component by default. You opt into Client Components by adding "use client" at the top of the file. The rule is simple: use Server Components for everything except interactive elements.
Server Components handle: data fetching, accessing backend resources, rendering static/dynamic content, heavy computations. Client Components handle: event listeners (onClick, onChange), browser APIs (localStorage, geolocation), React hooks (useState, useEffect, useRef), and real-time updates.
The key mental model is the "client boundary". When you mark a component with "use client", that component AND all components it imports become part of the client bundle. This is why you should push "use client" as far down the component tree as possible.
// ✅ Server Component (default in Next.js 15 — no directive needed) // Can be async, can access DB directly, sends ZERO JS to client async function BlogPosts() { const posts = await db.post.findMany({ orderBy: { createdAt: 'desc' }, take: 10, }); return ( <section> <h2>Latest Posts</h2> {posts.map(post => ( <article key={post.id}> <h3>{post.title}</h3> <p>{post.excerpt}</p> {/* Client Component at the leaf — only this ships JS */} <LikeButton postId={post.id} initialCount={post.likes} /> </article> ))} </section> ); } // ✅ Client Component — only this part ships JS to the browser 'use client'; import { useState } from 'react'; function LikeButton({ postId, initialCount }) { const [likes, setLikes] = useState(initialCount); return ( <button onClick={() => setLikes(prev => prev + 1)}> ❤️ {likes} </button> ); }
The use() Hook: React 19's Game Changer
React 19 introduces the use() hook — a fundamental new primitive that lets you read resources (Promises and Contexts) inside any component, including conditionals and loops. Unlike useContext, use() can be called conditionally.
For Server Components, use() enables a new streaming pattern where you pass a Promise from a Server Component to a Client Component, and the client can "unwrap" it with use() while showing a Suspense fallback.
This replaces the old pattern of await-ing everything on the server before sending. Now the shell renders instantly and data streams in progressively.
// Server Component — creates the promise but doesn't await it async function Dashboard() { // Don't await! Pass the promise directly const analyticsPromise = fetchAnalytics(); const revenuePromise = fetchRevenue(); return ( <div> <h1>Dashboard</h1> {/* Shell renders instantly, data streams in */} <Suspense fallback={<AnalyticsSkeleton />}> <AnalyticsPanel data={analyticsPromise} /> </Suspense> <Suspense fallback={<RevenueSkeleton />}> <RevenueChart data={revenuePromise} /> </Suspense> </div> ); } // Client Component — unwraps the promise with use() 'use client'; import { use } from 'react'; function AnalyticsPanel({ data }) { const analytics = use(data); // Suspends until resolved return ( <div> <p>Total Views: {analytics.views.toLocaleString()}</p> <p>Unique Visitors: {analytics.visitors.toLocaleString()}</p> </div> ); }
Key Takeaways
Server Actions: Mutations Without API Routes
Server Actions are async functions that run on the server, called directly from client components. They replace the need for API routes for mutations (form submissions, data updates, deletes). Mark them with "use server" directive.
Server Actions are deeply integrated with React's transitions system. When invoked, they automatically trigger a pending state, handle errors, and can revalidate cached data — all without manual fetch() calls or state management.
They work with both progressive enhancement (plain HTML forms without JS) and client-side interactivity.
// actions.ts — Server Actions live in their own file 'use server'; import { db } from '@/lib/db'; import { revalidatePath } from 'next/cache'; import { z } from 'zod'; const PostSchema = z.object({ title: z.string().min(3).max(200), content: z.string().min(10), category: z.enum(['Frontend', 'Backend', 'Database', 'DevOps']), }); export async function createPost(formData: FormData) { // Server-side validation const parsed = PostSchema.safeParse({ title: formData.get('title'), content: formData.get('content'), category: formData.get('category'), }); if (!parsed.success) { return { error: parsed.error.flatten().fieldErrors }; } await db.post.create({ data: parsed.data }); revalidatePath('/blog'); // Invalidate the blog listing cache } // Client Component using the Server Action 'use client'; import { useActionState } from 'react'; import { createPost } from './actions'; function CreatePostForm() { const [state, action, isPending] = useActionState(createPost, null); return ( <form action={action}> <input name="title" required /> <textarea name="content" required /> <button disabled={isPending}> {isPending ? 'Publishing...' : 'Publish'} </button> {state?.error && <p className="error">{JSON.stringify(state.error)}</p>} </form> ); }
Streaming SSR and Suspense Boundaries
React 19 supports streaming SSR out of the box. Instead of waiting for the entire page to render on the server before sending anything to the client, React streams HTML chunks as each Suspense boundary resolves.
This dramatically improves Time to First Byte (TTFB) and First Contentful Paint (FCP). Users see the page shell immediately while slower data loads streams in progressively.
Each Suspense boundary is an independent streaming unit. The server sends the fallback HTML first, then replaces it with the real content when the data is ready — all without client-side JavaScript for Server Components.
Key Takeaways
Partial Prerendering (PPR): The Best of Both Worlds
Partial Prerendering (PPR) in Next.js 15 is the most exciting rendering innovation since SSR itself. It combines static generation with dynamic streaming at the component level on a single route.
With PPR, the static shell of your page (header, footer, layout) is served instantly from the CDN edge, while dynamic parts (user-specific data, real-time content) stream in from the server. This gives you the speed of static sites with the freshness of dynamic pages.
PPR uses Suspense boundaries to determine what is static and what is dynamic. Anything outside a Suspense boundary is prerendered at build time. Anything inside one is rendered on-demand per request.
// next.config.ts — Enable PPR const nextConfig = { experimental: { ppr: true, }, }; // Page with PPR — static shell + dynamic content export default function ProductPage({ params }) { return ( <main> {/* ✅ STATIC: Prerendered at build time, served from CDN */} <Header /> <ProductDetails id={params.id} /> {/* ✅ DYNAMIC: Streamed per-request */} <Suspense fallback={<PriceSkeleton />}> <LivePrice id={params.id} /> {/* Real-time pricing */} </Suspense> <Suspense fallback={<ReviewsSkeleton />}> <UserReviews id={params.id} /> {/* User-specific content */} </Suspense> {/* ✅ STATIC */} <Footer /> </main> ); }
Composition Patterns: Avoiding the "use client" Cascade
The biggest mistake developers make with RSC is putting "use client" too high in the component tree. Once a component is marked as a Client Component, every component it imports also becomes a Client Component — inflating the bundle.
The solution is the "donut pattern": Server Components wrap Client Components, passing server-fetched data as props. Client Components are small, focused leaf nodes that handle only the interactive parts.
Another powerful pattern is passing Server Components as children to Client Components. Since children are just props, the Server Component is rendered on the server and passed as serialized RSC payload.
// ✅ DONUT PATTERN: Server Component wraps Client Component // ServerLayout.tsx — Server Component (default) async function ServerLayout() { const user = await getUser(); // Server-side data const navItems = await getNavItems(); // Server-side data return ( <div> {/* Pass server data DOWN to the interactive shell */} <InteractiveNav items={navItems} userName={user.name} /> {/* Server Component as children — rendered on server */} <Sidebar> <ServerSideRecommendations /> {/* This stays on the server! */} </Sidebar> </div> ); } // InteractiveNav.tsx — Client Component (leaf node) 'use client'; function InteractiveNav({ items, userName }) { const [isOpen, setIsOpen] = useState(false); return ( <nav> <button onClick={() => setIsOpen(!isOpen)}>☰</button> {isOpen && items.map(item => <a key={item.href} href={item.href}>{item.label}</a>)} <span>Welcome, {userName}</span> </nav> ); }
Key Takeaways
Caching and Revalidation in Next.js 15
Next.js 15 significantly changed its caching defaults. In Next.js 14, fetch() was cached by default. In Next.js 15, fetch() is NOT cached by default — you must opt into caching explicitly. This was the most requested change by the community.
There are four caching layers: Request Memoization (per-request dedup), Data Cache (cross-request persistence), Full Route Cache (prerendered pages), and Router Cache (client-side prefetch cache).
Understanding these layers is critical for production performance tuning and is a common interview topic for Next.js positions.
// Next.js 15: fetch() is NOT cached by default // You must explicitly set caching behavior // ✅ Static data — cache indefinitely const categories = await fetch('https://api.example.com/categories', { cache: 'force-cache', // Cached across requests }); // ✅ Revalidate every 60 seconds (ISR) const posts = await fetch('https://api.example.com/posts', { next: { revalidate: 60 }, }); // ✅ Always fresh — no caching const livePrice = await fetch('https://api.example.com/price', { cache: 'no-store', }); // ✅ On-demand revalidation via Server Action 'use server'; import { revalidateTag, revalidatePath } from 'next/cache'; export async function publishPost() { await db.post.create({ ... }); revalidateTag('blog-posts'); // Invalidate specific cached data revalidatePath('/blog'); // Regenerate entire route }
Interview Questions: React 19 & Server Components
Q1: What is the difference between SSR and RSC? → SSR sends HTML + full JS for hydration. RSC sends HTML + RSC payload — zero component JS on the client.
Q2: Can Server Components use useState or useEffect? → No. Server Components cannot use hooks that rely on client state or lifecycle. Only Client Components can.
Q3: What is the "use client" boundary? → It marks a component and all its imports as Client Components. Push it as deep as possible.
Q4: How does the use() hook differ from useContext? → use() can be called conditionally (inside if/else, loops). useContext cannot.
Q5: What are Server Actions? → Async functions marked with "use server" that run on the server but can be called from Client Components. They replace API routes for mutations.
Q6: What changed in Next.js 15 caching? → fetch() is no longer cached by default. You must explicitly opt into caching.
Q7: What is PPR? → Partial Prerendering: static shell from CDN + dynamic content streamed on-demand, on the same route.
Q8: Can you pass a Server Component as a child to a Client Component? → Yes! The Server Component renders on the server and is passed as serialized RSC payload via the children prop.
Q9: How does streaming work with Suspense? → The server sends fallback HTML immediately, then streams the real content when data resolves — replacing the fallback inline.
Q10: What is the RSC payload format? → A binary stream of serialized UI descriptions that React uses to reconcile the server-rendered tree on the client without hydration.
Key Takeaways
React 19 Server Components are the most significant React architecture change since Hooks. They eliminate the false choice between performance and developer experience by allowing components to run where they make the most sense — on the server for data, on the client for interactivity.
The key patterns to internalize: push "use client" to leaves, use the donut pattern for composition, stream data with Suspense + use(), and leverage Server Actions for mutations.
Next.js 15 is the production framework for RSC. Understand its 4 caching layers, PPR, and the breaking change to fetch() default behavior.