React Server Components: The Mental Model Shift for Senior Engineers

For 10 years, we have been building Single Page Applications (SPAs). The formula was simple:

1. 2.
   Send a blank HTML shell.
2. 4.
   Send a massive JS bundle (React, Router, Redux, Libraries).
3. 6.
   Browser executes JS.
4. 8.
   JS fetches data from API.
5. 10.
   UI renders.

It was interactive. It was smooth. But it was slow. The "Time to Interactive" (TTI) suffered because we force the user's phone to do all the work.

Server Side Rendering (SSR) helped (Step 1 sends HTML with data), but we still had to "Hydrate" the entire page with the same massive JS bundle.

Enter React Server Components (RSC).

RSC is not just a performance optimization. It is a new Mental Model. It allows us to render components on the server and stream the result to the client, without sending any JavaScript for that component.

If you import moment.js in a Server Component, the user never downloads moment.js. The server runs it, generates the date string, and sends the string.

This 4,000-word guide is for senior engineers who want to understand how to think in RSC.

Part 1: The Boundary (Server vs. Client)

In the App Router (Next.js 13+), everything is a Server Component by default. You have to opt-in to the Client.

The Server World (page.tsx)

• Capabilities: Can access Database, Filesystem, Secrets.
• Limitations: No useState, useEffect, onClick, window.
• Output: Serialized UI (Virtual DOM JSON).

The Client World ("use client")

• Capabilities: Interaction, State, Browser APIs.
• Limitations: Large bundle size.
• Output: HTML + JavaScript.

The Golden Rule: Push the "Client Boundary" as far down the tree as possible.

Bad Pattern:

tsx
// page.tsx ("use client")
export default function Page() {
  const [data, setData] = useState(null);
  useEffect(() => { fetch('/api/data').then(setData) }, []);
  return <Chart data={data} />;
}

This makes the entire page a client bundle.

Good Pattern:

tsx
// page.tsx (Server Component - Default)
const data = await db.query('SELECT * FROM stats'); // Direct DB call!

export default function Page() {
  return <Chart data={data} />; // Pass data as props
}

// Chart.tsx ("use client")
'use client';
export default function Chart({ data }) {
  // Only this component is sent as JS
  return <InteractiveChart data={data} />;
}

Part 2: Async Components & Data Fetching

In RSC, components can be async. This kills the need for useEffect fetching.

tsx
async function UserProfile({ id }) {
  const user = await db.user.findUnique({ where: { id } });
  
  return (
    <div>
      <h1>{user.name}</h1>
      <Suspense fallback={<Skeleton />}>
        <UserPosts id={id} />
      </Suspense>
    </div>
  );
}

Here, UserPosts can also be async. We can fetch data granularly.

The Waterfall Problem

If UserProfile awaits user, and then renders UserPosts (which awaits posts), we have a Sequential Waterfall.

1. 2.
   Fetch User (100ms)
2. 4.
   Render User
3. 6.
   Fetch Posts (200ms)
4. 8.
   Render Posts Total: 300ms.

Parallel Data Fetching: You can start both fetches at the top level.

tsx
async function Page({ id }) {
  // Start both promises
  const userData = getUser(id);
  const postsData = getPosts(id);

  // Wait for both? Or await individually?
  const [user, posts] = await Promise.all([userData, postsData]);
  
  return <Profile user={user} posts={posts} />;
}

But this blocks the entire UI until the slowest request finishes.

Streaming with Suspense: The best mental model is Streaming. Don't await the slow stuff at the top. Pass the promise? No, let the component handle it. Wrap the slow component in Suspense. Next.js will stream the HTML for the fast parts (User) immediately, and keep a connection open to stream the slow parts (Posts) when they are ready.

Part 3: Interleaving Server and Client

A common misconception: "You can't import a Server Component into a Client Component."

False. You can't import it directly, but you can pass it as a children prop.

The Problem: If Sidebar is a Client Component (needs state for "isOpen"), and ServerList is a Server Component (fetches DB), you can't do:

tsx
// CLIENT COMPONENT
'use client';
import ServerList from './ServerList'; // ERROR!

The Solution (Composition): Pass it from a parent Server Component.

tsx
// page.tsx (Server)
import Sidebar from './Sidebar';
import ServerList from './ServerList';

export default function Page() {
  return (
    <Sidebar>
      <ServerList /> {/* Passed as generic "children" */}
    </Sidebar>
  );
}

// Sidebar.tsx (Client)
'use client';
export default function Sidebar({ children }) {
  const [isOpen, setIsOpen] = useState(true);
  return (
    <div>
      <button onClick={() => setIsOpen(!isOpen)}>Toggle</button>
      {isOpen && children} {/* Renders the Server Component output */}
    </div>
  );
}

The children prop is already rendered (as serialized JSON) by the server. The Client Component just places it in the DOM.

Part 4: Server Actions (The Mutation Story)

RSC handles fetching. Server Actions handle mutations (POST/PUT/DELETE).

You define a function on the server, and you can call it directly from a button onClick (or form action) on the client.

tsx
// actions.ts
'use server';

export async function likePost(postId: string) {
  await db.post.update({
    where: { id: postId },
    data: { likes: { increment: 1 } }
  });
  revalidatePath('/posts'); // Tell UI to refresh
}

// LikeButton.tsx ('use client')
import { likePost } from './actions';

export default function LikeButton({ id }) {
  return <button onClick={() => likePost(id)}>Like</button>;
}

This eliminates the need for:

1. 2.
   Creating /api/like route handler.
2. 4.
   Writing fetch('/api/like', method: 'POST').
3. 6.
   Handling serialization manually.

It feels like calling a local function. It is actually an RPC (Remote Procedure Call).

Part 5: The Bundle Size Win

Let's look at a markdown blog engine. Traditional (SPA):

• Bundle includes: React + marked (markdown parser) + sanitize-html + shiki (syntax highlighter).
• Size: 400kB of JS.
• User downloads 400kB just to read text.

RSC:

• Server Component imports marked, sanitize, shiki.
• Server renders specific HTML (<pre><code>...</code></pre>).
• Sends HTML to client.
• Client Bundle: 0kB (for this feature).

This is why my portfolio scores 100 on Lighthouse Performance. I perform heavy lifting (analyzing blogs, formatting dates, syntax highlighting) on the server. The browser just receives semantic HTML.

Conclusion: The "Hybrid" Future

Web development is cyclic. We started with Server-Side (PHP/Rails). We moved to Client-Side (SPA/React). We are now settling in the middle: Hybrid.

React Server Components give us the best of both worlds.

• Server: Data connection, Security, Performance (Zero Bundle).
• Client: Interactivity, Immediate Feedback.

The learning curve is steep. You have to think about where your code runs. But once it clicks, you realize this is how we should have been building apps all along.

The browser is for interaction. The server is for data. RSC finally respects that separation.

Resources

• React Docs: Server Components
• Next.js App Router Documentation
• Dan Abramov on RSC

About the Author: Sachin Sharma uses RSC extensively to build high-performance dashboards and content platforms. He believes the "Client Boundary" is the most important architectural decision in modern React.