React Server Components represent a fundamental shift in how React applications are architected — one that goes deeper than just moving rendering to the server. The core insight is that the component tree is now split across two environments: server components fetch data and render HTML, client components manage interactivity. Understanding the boundaries, the serialisation model, and the performance implications requires building a new mental model. This guide provides the conceptual foundations and practical patterns for thinking in RSC correctly.
The Two-Environment Mental Model
The single most important concept in RSC is that every component in your tree lives in one of two environments, and the rules for each are completely different.
- Server Components: Run only on the server. Can use async/await, access databases directly, read files, use server-only secrets
- Client Components: Run on both server (for initial HTML) and browser (for interactivity). Cannot be async at the component level
- "use client" is a boundary declaration, not "this runs only in the browser"
- All components are Server Components by default in Next.js App Router
- Server Components cannot use hooks, event handlers, or browser-only APIs
- Client Components can import Server Components? No — but Server Components can pass RSC as children to Client Components
Data Fetching Patterns in RSC
RSC changes data fetching fundamentally. Instead of useEffect + fetch in client components, data fetching happens at the component level — closer to where the data is actually used.
- Async Server Components: async function Page() { const data = await fetch(...) — data available synchronously in JSX
- Parallel data fetching with Promise.all: No waterfall delays when multiple fetches are independent
- Component-level fetching: Each component fetches its own data, colocated with the UI that uses it
- No more prop drilling of data: Parent fetches, passes to 5 children — now each child fetches its own
- Streaming with Suspense: Wrap slow components in Suspense, stream them in as they resolve
- React cache() function: Deduplicate identical fetches made by multiple components in one render
When to Use Client Components
Over-using Client Components negates the benefits of RSC. The principle is to push interactivity to the leaves of the component tree, keeping as much as possible on the server.
- Use client for: useState, useEffect, event handlers, browser APIs, interactive widgets
- Keep parent layouts, data-fetching wrappers, and static content as Server Components
- Client boundary at the leaf: Button, Modal, Form — not the entire page or layout
- Third-party components that use hooks automatically require a client boundary wrapper
- Context providers must be Client Components — wrap as low in the tree as possible
- The "client module graph" increases bundle size — minimise what crosses the boundary
Conclusion
React Server Components are not an incremental feature — they require rebuilding your mental model of where code runs and how data flows through an application. The teams getting the most out of RSC are those who treat Server Components as the default, use Client Components only for interactivity, and leverage streaming with Suspense for perceived performance. Sensussoft's frontend engineering team has migrated and architected dozens of Next.js applications on the App Router with RSC, consistently achieving 40–60% reductions in JavaScript bundle size and dramatic improvements in Time to First Byte (TTFB).
About Jessica Kim
Jessica Kim is a technology expert at Sensussoft with extensive experience in web development. They specialize in helping organizations leverage cutting-edge technologies to solve complex business challenges.
