Q175: React Server Components and Client Boundaries in Next.js

What Interviewers Want To Evaluate

This question checks whether you understand Server Components as an architecture boundary. Interviewers want server vs client component responsibilities, use client, serializable props, data fetching, bundle size, hydration, interactivity islands, security, caching, Server Actions, and migration strategy.

Senior answers should explain how boundaries reduce client JavaScript without harming product ergonomics.

Short Interview Answer

React Server Components render on the server and do not ship their component code to the browser. They are good for data fetching, static or server-derived UI, markdown/content rendering, database reads, and composing client islands. Client Components are needed for state, effects, event handlers, browser APIs, refs, and interactive behavior. In Next.js App Router, components are Server Components by default, and "use client" marks a client boundary.

Detailed Interview Answer

In the Next.js App Router, files are Server Components by default.

export default async function ProductPage({ params }) {
  const product = await getProduct(params.id);
  return <ProductDetails product={product} />;
}

This component can fetch server data directly.

It does not need to ship its component code to the browser.

Client Boundary

Add "use client" when browser interactivity is required.

"use client";

export function AddToCartButton({ productId }) {
  const [pending, setPending] = useState(false);

  return <button onClick={() => addToCart(productId)}>Add</button>;
}

Client Components can use hooks, event handlers, browser APIs, and refs.

Server Responsibilities

Server Components are good for:

data fetching
auth-aware reads
content rendering
layout composition
large dependency usage
formatting server-derived data
passing serializable props to client islands
reducing client bundle size

They keep work out of the browser when the browser does not need to own it.

Client Responsibilities

Client Components are needed for:

useState and useReducer
useEffect and browser synchronization
event handlers
forms with rich client validation
DOM refs
local storage
media queries
drag and drop
interactive charts

The client boundary should be as small as practical.

Serializable Props

Server Components pass data to Client Components through serialized props.

Avoid passing:

functions
class instances
database clients
non-serializable objects
secrets
large unnecessary payloads

Pass plain data with explicit shape.

Interactivity Islands

A strong pattern is server shell plus client islands.

export default async function ArticlePage() {
  const article = await getArticle();

  return (
    <article>
      <MarkdownContent source={article.body} />
      <BookmarkButton articleId={article.id} />
    </article>
  );
}

The article renders on the server. The bookmark button hydrates on the client.

Bundle Size

Server Components can reduce bundle size because server-only component code and server-only dependencies do not become client JavaScript.

This matters for:

markdown renderers
syntax highlighters
date formatting utilities
CMS adapters
database libraries
large server-only SDKs

But importing a server-heavy module into a Client Component can pull cost back to the browser or fail.

Hydration

Client Components hydrate.

Server Components do not hydrate as components on the client.

The browser receives rendered output and a payload that lets React connect server and client trees.

Hydration cost is one reason to avoid making entire pages client components.

Security

Server Components can access server-only data, but you must still enforce authorization on the server.

Do not pass secrets to Client Components.

Do not rely on hidden UI for permissions.

Sensitive checks belong in server data functions, Server Actions, or Route Handlers.

Caching and Revalidation

Server Components work with framework caching and revalidation patterns.

Think about:

static content
per-request user data
stale-while-revalidate data
tag or path revalidation
private data boundaries

Rendering location and caching policy should match data sensitivity and freshness.

Server Actions

Server Actions pair well with Server Components and forms.

The page can render server data, and mutations can happen on the server.

Client Components can still provide optimistic UI and pending feedback.

The important part is keeping mutation authority server-side.

Common Mistakes

A common mistake is adding "use client" to a whole route because one button is interactive.

Another mistake is passing non-serializable data across the boundary.

Another mistake is importing server-only modules into Client Components.

Another mistake is over-fetching and sending large payloads to small client islands.

Another mistake is forgetting authorization because a page "renders on the server."

Senior Trade-Offs

Server Components improve performance and architecture when boundaries are clear.

They can also complicate mental models for teams used to all-client React.

Migration should be incremental: move data-heavy static sections server-side, keep interaction islands focused, and document boundary rules.

Debugging Workflow

When a Server Component boundary breaks:

check for accidental useState or event handlers
check where use client is declared
inspect non-serializable props
inspect imports crossing boundaries
measure client bundle impact
verify auth checks server-side
review caching behavior
test hydration and interaction islands

Interview Framing

Define Server Components, explain Client Component boundaries, discuss serialization, hydration, bundle size, security, caching, and migration.

Revision Notes

Server Components move non-interactive work out of the browser. Client Components own interaction.

Key Takeaways

Push client boundaries down. Keep data and authority on the server, and hydrate only the pieces that need browser behavior.

Follow-Up Questions

1. What is a Server Component?
2. What does "use client" do?
3. When is a Client Component required?
4. What props can cross the boundary?
5. Why do Server Components help bundle size?
6. What hydrates in this model?
7. How do Server Actions fit?
8. What security mistakes are common?
9. How should caching be chosen?
10. How would you migrate an all-client page?

How I Would Answer This In A Real Interview

I would say Server Components render on the server and keep non-interactive work out of the browser, while Client Components own hooks, effects, events, refs, and browser APIs. In Next.js, I would keep pages server-first, push "use client" down to focused islands, pass only serializable data, and enforce authorization on the server.