Server Components are React components that render entirely on the server and ship only their finished HTML to the browser — no component JavaScript included.

Think of a restaurant menu printed fresh each morning versus a whiteboard the waiter updates live at your table. The printed menu (a Server Component) is cheap to produce and needs no ongoing attention once it reaches you. The whiteboard (a Client Component) costs more to maintain but can react to you in real time. A well-built page uses mostly printed menus, with a whiteboard only where interaction is actually needed. Most developers struggle with Server Components because they learn the rules before they understand this why.

The Problem Server Components Solve

Traditional React apps (Create React App, Vite) have a fundamental issue: everything runs in the browser.

code

User requests page → Browser gets empty HTML → Downloads JS bundle → 
React runs in browser → Renders components → User sees content

Problems with this:

Large bundles — every dependency ships to the browser
Slow initial load — user waits for JS to download, parse, execute
Server secrets can't be used — API keys, database connections in the browser
Waterfall requests — component loads, then fetches data, then child fetches data

Server Components run on the server. They render to HTML before the browser gets involved.

The Mental Model: Two Worlds

Imagine your app split into two distinct environments:

code

┌─────────────────────────────────┐
│           SERVER                │
│  - Has database access          │
│  - Has secrets/API keys         │
│  - No interactivity             │
│  - Renders to HTML              │
│  - Server Components live here  │
└────────────────┬────────────────┘
                 │ HTML + RSC payload
┌────────────────▼────────────────┐
│           BROWSER               │
│  - Has interactivity            │
│  - Has event handlers           │
│  - Has state (useState)         │
│  - No database/secrets          │
│  - Client Components live here  │
└─────────────────────────────────┘

Server Components: Render on server, generate HTML. Can access databases directly. Cannot use hooks, event handlers, or browser APIs.

Client Components: Run in browser. Have interactivity. Cannot access database directly.

In Next.js App Router

By default, every component is a Server Component.

You opt into a Client Component with 'use client' at the top of the file:

jsx

// ProductPage.tsx — Server Component (default, no directive)
import { db } from '@/lib/db';  // Direct database access ✓

async function ProductPage({ params }: { params: { id: string } }) {
    // Fetch data directly — no API route needed!
    const product = await db.query(
        'SELECT * FROM products WHERE id = ?',
        [params.id]
    );
    
    return (
        <div>
            <h1>{product.name}</h1>
            <p>${product.price}</p>
            <AddToCartButton productId={product.id} />  {/* Client Component */}
        </div>
    );
}

jsx

// AddToCartButton.tsx — Client Component
'use client';

import { useState } from 'react';

function AddToCartButton({ productId }: { productId: number }) {
    const [added, setAdded] = useState(false);
    
    return (
        <button onClick={() => {
            addToCart(productId);
            setAdded(true);
        }}>
            {added ? '✓ Added!' : 'Add to Cart'}
        </button>
    );
}

The Composition Pattern

You can render Client Components inside Server Components. The key: data flows down, not up.

jsx

// Server Component — can do async, DB queries, access secrets
async function Dashboard() {
    const [user, stats, recentOrders] = await Promise.all([
        db.getUser(userId),
        db.getStats(userId),
        db.getRecentOrders(userId, 10),
    ]);
    
    return (
        <div className="dashboard">
            <UserHeader user={user} />              {/* Could be Server Component */}
            <StatsGrid stats={stats} />             {/* Server Component */}
            <InteractiveChart data={stats.chartData} />  {/* Client Component — has hover/filter */}
            <OrderTable orders={recentOrders} />    {/* Server Component */}
            <NotificationBell userId={user.id} />   {/* Client Component — has real-time */}
        </div>
    );
}

The result: most of the page is static HTML from the server. Only the interactive parts ship JavaScript.

What Can and Can't Each Component Type Do

Capability	Server Component	Client Component
`async/await` (top level)	✓	✗
Direct database queries	✓	✗
Access env variables (secrets)	✓	Only public ones
`useState` / `useEffect` hooks	✗	✓
Event handlers (onClick, etc.)	✗	✓
Browser APIs (window, document)	✗	✓
Render Server Components as children	✓	Only via `children` prop
Import Client Components	✓	✓

The "Passing Children" Pattern

Client Components can contain Server Components if they receive them as children:

jsx

// 'use client' — this is a Client Component
'use client';
function Modal({ children }: { children: React.ReactNode }) {
    const [open, setOpen] = useState(false);
    return (
        <div>
            <button onClick={() => setOpen(!open)}>Toggle</button>
            {open && <div className="modal">{children}</div>}
        </div>
    );
}

// Server Component — renders a Client Component with Server Component children
async function Page() {
    const data = await db.getExpensiveData();   // Server-side
    return (
        <Modal>
            <DataDisplay data={data} />  {/* Server Component as children */}
        </Modal>
    );
}

DataDisplay is still a Server Component — it rendered on the server. Modal is a Client Component with interactivity. They work together.

Why This Matters for Performance

A traditional React app for a dashboard:

code

Bundle: React (45KB) + App (120KB) + Chart library (80KB) + Data grid (95KB) = ~340KB
Time to interactive: ~3-5 seconds on mobile

With Server Components:

code

Server renders: Dashboard HTML + StatsGrid HTML + OrderTable HTML
Bundle: React (45KB) + AddToCartButton (2KB) + InteractiveChart (80KB) = ~127KB
Time to interactive: <1 second on mobile (HTML already there)

Only interactive components need to ship JavaScript. Read-only content becomes pure HTML.

The Decision Framework

Ask yourself: Does this component need to be interactive?

No interactivity needed? → Server Component
Uses useState, useEffect, or event handlers? → Client Component
Uses browser APIs? → Client Component
Fetches data that must be real-time on client? → Client Component
Everything else? → Server Component (the default)

Rule of thumb: Push 'use client' as deep in the component tree as possible. The more Server Components you have, the better your performance.

Next lesson: When to Use Client Components — a practical decision guide for the boundary between server and client.

💬 DiscussionPowered by GitHub Discussions

📱

Get this course's notes on Telegram!

Free cheat sheets, summaries & practice exercises

Get Notes Free →

20 minLesson 18 of 33

Course Contents(33 lessons)

▾

React Core Concepts

React 19 Fundamentals & JSX14 min

Components: Thinking in React18 min

Props & Component Composition16 min

useState: State Management20 min

useEffect: Side Effects Mastery22 min

Event Handling & Synthetic Events14 min

Advanced React Patterns

Context API & useContext20 min

useReducer for Complex State18 min

useMemo & useCallback: Performance16 min

useRef & Forwarding Refs16 min

Custom Hooks: Reusable Logic22 min

React.memo & Avoiding Re-renders18 min

Next.js App Router

Next.js 15 Architecture Overview16 min

Layouts & Nested Layouts18 min

Loading UI & Suspense16 min

Error Boundaries & not-found14 min

Route Groups & Parallel Routes18 min

Server & Client Components

The Server Component Mental Model20 min

When to Use Client Components16 min

Server Actions & Form Handling22 min

Streaming & Suspense Boundaries18 min

Data Fetching & Caching

Next.js Caching Strategies Explained24 min

SWR & React Query for Client Fetching22 min

Optimistic Updates & Mutations18 min

Authentication

Auth Overview: Sessions vs JWT vs OAuth18 min

NextAuth.js v5 Setup26 min

Protected Routes & Middleware20 min

Styling & UI

Tailwind CSS in Next.js16 min

Shadcn UI Component Library20 min

Dark Mode Implementation14 min

Testing & Deployment

Testing React with Vitest & Testing Library26 min

Deploy to Vercel: Production Setup18 min

Performance Optimization & Core Web Vitals22 min

Server & Client Components

The Server Component Mental Model

Server Components are React components that render entirely on the server and ship only their finished HTML to the browser — no component JavaScript included.

The Problem Server Components Solve

Traditional React apps (Create React App, Vite) have a fundamental issue: everything runs in the browser.

code

User requests page → Browser gets empty HTML → Downloads JS bundle → 
React runs in browser → Renders components → User sees content

Problems with this:

Large bundles — every dependency ships to the browser
Slow initial load — user waits for JS to download, parse, execute
Server secrets can't be used — API keys, database connections in the browser
Waterfall requests — component loads, then fetches data, then child fetches data

Server Components run on the server. They render to HTML before the browser gets involved.

The Mental Model: Two Worlds

Imagine your app split into two distinct environments:

code

┌─────────────────────────────────┐
│           SERVER                │
│  - Has database access          │
│  - Has secrets/API keys         │
│  - No interactivity             │
│  - Renders to HTML              │
│  - Server Components live here  │
└────────────────┬────────────────┘
                 │ HTML + RSC payload
┌────────────────▼────────────────┐
│           BROWSER               │
│  - Has interactivity            │
│  - Has event handlers           │
│  - Has state (useState)         │
│  - No database/secrets          │
│  - Client Components live here  │
└─────────────────────────────────┘

Server Components: Render on server, generate HTML. Can access databases directly. Cannot use hooks, event handlers, or browser APIs.

Client Components: Run in browser. Have interactivity. Cannot access database directly.

In Next.js App Router

By default, every component is a Server Component.

You opt into a Client Component with 'use client' at the top of the file:

jsx

// ProductPage.tsx — Server Component (default, no directive)
import { db } from '@/lib/db';  // Direct database access ✓

async function ProductPage({ params }: { params: { id: string } }) {
    // Fetch data directly — no API route needed!
    const product = await db.query(
        'SELECT * FROM products WHERE id = ?',
        [params.id]
    );
    
    return (
        <div>
            <h1>{product.name}</h1>
            <p>${product.price}</p>
            <AddToCartButton productId={product.id} />  {/* Client Component */}
        </div>
    );
}

jsx

// AddToCartButton.tsx — Client Component
'use client';

import { useState } from 'react';

function AddToCartButton({ productId }: { productId: number }) {
    const [added, setAdded] = useState(false);
    
    return (
        <button onClick={() => {
            addToCart(productId);
            setAdded(true);
        }}>
            {added ? '✓ Added!' : 'Add to Cart'}
        </button>
    );
}

The Composition Pattern

You can render Client Components inside Server Components. The key: data flows down, not up.

jsx

// Server Component — can do async, DB queries, access secrets
async function Dashboard() {
    const [user, stats, recentOrders] = await Promise.all([
        db.getUser(userId),
        db.getStats(userId),
        db.getRecentOrders(userId, 10),
    ]);
    
    return (
        <div className="dashboard">
            <UserHeader user={user} />              {/* Could be Server Component */}
            <StatsGrid stats={stats} />             {/* Server Component */}
            <InteractiveChart data={stats.chartData} />  {/* Client Component — has hover/filter */}
            <OrderTable orders={recentOrders} />    {/* Server Component */}
            <NotificationBell userId={user.id} />   {/* Client Component — has real-time */}
        </div>
    );
}

The result: most of the page is static HTML from the server. Only the interactive parts ship JavaScript.

What Can and Can't Each Component Type Do

Capability	Server Component	Client Component
`async/await` (top level)	✓	✗
Direct database queries	✓	✗
Access env variables (secrets)	✓	Only public ones
`useState` / `useEffect` hooks	✗	✓
Event handlers (onClick, etc.)	✗	✓
Browser APIs (window, document)	✗	✓
Render Server Components as children	✓	Only via `children` prop
Import Client Components	✓	✓

The "Passing Children" Pattern

Client Components can contain Server Components if they receive them as children:

jsx

// 'use client' — this is a Client Component
'use client';
function Modal({ children }: { children: React.ReactNode }) {
    const [open, setOpen] = useState(false);
    return (
        <div>
            <button onClick={() => setOpen(!open)}>Toggle</button>
            {open && <div className="modal">{children}</div>}
        </div>
    );
}

// Server Component — renders a Client Component with Server Component children
async function Page() {
    const data = await db.getExpensiveData();   // Server-side
    return (
        <Modal>
            <DataDisplay data={data} />  {/* Server Component as children */}
        </Modal>
    );
}

DataDisplay is still a Server Component — it rendered on the server. Modal is a Client Component with interactivity. They work together.

Why This Matters for Performance

A traditional React app for a dashboard:

code

Bundle: React (45KB) + App (120KB) + Chart library (80KB) + Data grid (95KB) = ~340KB
Time to interactive: ~3-5 seconds on mobile

With Server Components:

code

Server renders: Dashboard HTML + StatsGrid HTML + OrderTable HTML
Bundle: React (45KB) + AddToCartButton (2KB) + InteractiveChart (80KB) = ~127KB
Time to interactive: <1 second on mobile (HTML already there)

Only interactive components need to ship JavaScript. Read-only content becomes pure HTML.

The Decision Framework

Ask yourself: Does this component need to be interactive?

No interactivity needed? → Server Component
Uses useState, useEffect, or event handlers? → Client Component
Uses browser APIs? → Client Component
Fetches data that must be real-time on client? → Client Component
Everything else? → Server Component (the default)

Rule of thumb: Push 'use client' as deep in the component tree as possible. The more Server Components you have, the better your performance.

Next lesson: When to Use Client Components — a practical decision guide for the boundary between server and client.

💬 DiscussionPowered by GitHub Discussions

📱

Get this course's notes on Telegram!

Free cheat sheets, summaries & practice exercises

Get Notes Free →