Server vs Client Components in Next.js

In the Next.js 15 App Router, every component is a React Server Component (RSC) by default. That means it runs on the server, never ships to the browser as JavaScript, and can await server resources directly — databases, files, secrets.

// app/posts/page.tsx (Server Component)
import { db } from '@/lib/db';

export default async function PostsPage() {
  const posts = await db.posts.list();   // direct DB call, server-only
  return <ul>{posts.map(p => <li key={p.id}>{p.title}</li>)}</ul>;
}

The component above sends zero JS to the client. The browser receives HTML with the data already rendered. No useEffect, no loading spinner, no fetch wrapper. This is the biggest reset in React patterns since hooks.

When you need state, effects, browser APIs, or event handlers, you opt that component into being a Client Component with a directive at the top of the file:

'use client';
import { useState } from 'react';

export function Counter() {
  const [n, setN] = useState(0);
  return <button onClick={() => setN(n + 1)}>{n}</button>;
}

The directive marks a boundary. Everything imported transitively from this file is now part of the client bundle. A Server Component can render Client Components (it just sends the component tree as data), but a Client Component cannot render a Server Component as a child — it can only accept one as a children prop.

Server Components render on the server; Client Components hydrate in the browser. Props cross the boundary as serialized data.

Props from a Server Component to a Client Component must be serializable. The set is roughly: primitives, arrays, plain objects, Dates, Maps, Sets, Promises, JSX elements (yes), and other Server Components passed as children.

The set explicitly does NOT include: functions, class instances, DB connection objects, anything non-serializable.

// ✅ allowed: pre-fetched data
<LikeButton postId={post.id} initialLikes={post.likes} />

// ❌ disallowed: a function defined in the server component
<LikeButton onLike={() => db.likes.add(post.id)} />

The right way to ship behavior across the boundary is Server Actions — covered next.

A Server Action is a function annotated with 'use server' that the framework exposes to the client as a callable. Under the hood it's an RPC, but it looks like a regular function import.

// app/actions/likes.ts
'use server';
import { revalidatePath } from 'next/cache';
import { db } from '@/lib/db';

export async function likePost(postId: string) {
  await db.likes.create({ postId, userId: getCurrentUserId() });
  revalidatePath(`/posts/${postId}`);   // refresh server-rendered HTML
}

Any client component can import and call it as if it ran locally:

'use client';
import { likePost } from '@/app/actions/likes';
<button onClick={() => likePost(id)}>Like</button>

Next.js handles the wire format, CSRF protection, and serialization. From the browser's view: a network round-trip; from your code's view: a function call.

Server Actions slot directly into the <form action={...}> prop in React 19. No event.preventDefault, no fetch, no useState for form fields:

// server action
'use server';
export async function createPost(formData: FormData) {
  const title = String(formData.get('title'));
  await db.posts.create({ title });
  revalidatePath('/posts');
}

// usage in a page (can be a Server Component!)
import { createPost } from './actions';

export default function NewPost() {
  return (
    <form action={createPost}>
      <input name="title" />
      <button type="submit">Create</button>
    </form>
  );
}

For pending states and optimistic updates, sprinkle in useActionState and useOptimistic on the client. But the baseline — form posts that mutate the DB — works without a single line of client JS.

Slow data shouldn't block the rest of the page. Wrap the slow Server Component in <Suspense> and Next streams the placeholder first, then the data.

import { Suspense } from 'react';

export default function Dashboard() {
  return (
    <>
      <Header />                          {/* renders instantly */}
      <Suspense fallback={<Skeleton />}>
        <SlowRecommendations />           {/* awaits 2s, streams in */}
      </Suspense>
    </>
  );
}

The browser sees <Header /> and the skeleton immediately. The skeleton's HTML carries a placeholder marker; when the server finishes SlowRecommendations, Next streams the real HTML and a tiny <script> that swaps it in. From a user's perspective: faster first paint and a single page, not a spinner-then-page.

Rule of thumb:

The pattern is: push 'use client' as far down the tree as possible. A page that ends up 95% server-rendered with a small client island for the comment form is the ideal shape. You ship less JS, hydrate less HTML, and the page is fast on cheap phones.

Here's the canonical pattern: server reads data, hands typed data to a client component for interactivity.

// app/posts/page.tsx — Server Component
import { db } from '@/lib/db';
import { PostCard } from './post-card';

export default async function PostsPage() {
  const posts = await db.post.findMany({
    select: { id: true, title: true, likes: true },
  });
  return (
    <ul>
      {posts.map(p => <PostCard key={p.id} post={p} />)}
    </ul>
  );
}

// app/posts/post-card.tsx — Client Component
'use client';
import { likePost } from '@/app/actions/likes';

export function PostCard({ post }: { post: { id: string; title: string; likes: number } }) {
  return (
    <li>
      {post.title}
      <button onClick={() => likePost(post.id)}>{post.likes} ♥</button>
    </li>
  );
}

Server fetches and types the data. Client owns the interaction. The Server Action closes the loop with a real DB write.

Five mistakes that bite everyone in the first month:

1. Adding 'use client' to the root layout — turns the entire app into a client bundle. Almost never what you want.
2. Importing server-only code into a client component — you'll get a build error. The fix is to call it via a Server Action instead.
3. Passing event handlers from Server → Client — handlers are functions; functions don't serialize. Use Server Actions.
4. Forgetting revalidatePath / revalidateTag — your mutation succeeds but the listing page keeps showing stale data because it's been cached.
5. Reaching for useEffect to fetch data on a page — almost always the wrong move now. Fetch in the Server Component above, pass data down as props.

Get these right and the App Router stops surprising you.