Server Components by Default

In the Next.js app directory, every component is a server component by default. There is no special annotation required to run on the server—it's the implicit behavior. This means the component's JavaScript is not sent to the browser, and it can directly import and use Node.js APIs, read from the filesystem, fetch databases, and more. This fundamental design choice is what makes the Next.js app router so powerful for building performance-oriented applications. When you create a component in the app directory, it automatically runs on the server. You don't need to add any special directives or configuration. This implicit server-side rendering is a departure from the Pages router, where you had to deliberate about whether a component should be server-side or client-side. The app directory flips this paradigm, making server components the default and client components the explicit opt-in.

Zero JavaScript sent to the client: Because server components render on the server, their JavaScript bundle is not included in the client payload. This dramatically reduces the amount of JavaScript the browser must execute, which improves time-to-interactive and overall performance. The HTML and CSS are sent, but the .js code stays on the server. In practice, a page that might have sent 500KB of JavaScript with the Pages router might only send 50KB with the app router and server components. The performance impact is substantial, especially on mobile devices with limited bandwidth and processing power. This is often the first thing interviewers ask about when evaluating Next.js knowledge.

Direct data fetching: Server components can import and use any Node.js API directly. This is one of their most powerful features. Server components can:

• Use fetch() for API routes or external services. The fetch runs on the server, and the result is streamed to the client.
• Import and use database drivers such as Prisma, Drizzle, MongoDB, or any other ORM/ODM. The database query runs on the server, and only the result data is sent to the client.
• Perform file system operations via fs.readFile, fs.writeFile, and other Node.js APIs. This is useful for generating dynamic HTML, reading configuration files, or any build-time data processing.
• Access environment variables via process.env. Variables without the NEXT_PUBLIC_ prefix are server-only and never included in the client bundle.
• Import server-only modules. Next.js marks certain modules as server-only, ensuring they never reach the browser.

Code example: Consider a product page that fetches data from a database:

// app/products/[id]/page.js — server component
export default async function ProductPage({
  params
}) {
  const product = await prisma.product.findUnique({
    where: { id: params.id }
  })
  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
    </div>
  )
}

In this example, the prisma.product.findUnique query runs on the server. The HTML sent to the client includes the product name and description, but the Prisma client and the query logic never reach the browser.

What server components cannot do: Despite their power, server components have intentional limitations:

• They cannot use client-side only hooks (useState, useEffect, useContext). These hooks are exclusive to client components and will cause a build error if used in a server component.
• They cannot use event handlers (onClick, onSubmit, onChange). Events are handled on the browser, so components with event handlers must be client components.
• Their code is stripped from the client bundle entirely. This means you cannot rely on server component code running on the client.
• They cannot access window, document, or the browser DOM directly. Server components run on the Node.js runtime, not the browser.
• They cannot use useEffect for side effects after render. Data fetching must happen synchronously in the component body.

Interop with client components: Server components can render client components by importing them. This is the primary way to mix static, data-rich markup with interactive UI. The server component renders the HTML, and the client component adds interactivity on the browser side. This interop is the foundation of the island architecture pattern, where most of the page is server-rendered, and only small, discrete components that need interactivity are marked as client components.

// app/products/[id]/page.js — server component
import ProductDetails from './product-details'

export default function ProductPage({
  params
}) {
  const product = await prisma.product.findUnique({
    where: { id: params.id }
  })
  return (
    <>\n      <h1>{product.name}</h1>\n      <ProductDetails />  {/* client component for interactivity */}\n    </>\n  )
}

// ./product-details.js — client component
'use client'
import { useState } from 'react'

export function ProductDetails() {
  const [expanded, setExpanded] = useState(false)
  return (
    <button onClick={() => setExpanded(!expanded)}>
      {expanded ? 'Less' : 'More'}
    </button>
  )
}

Why this matters in interviews: When asked about the default server component behavior, a strong answer explains that the app directory assumes server components by default, which reduces client JavaScript and enables direct data fetching. Mentioning the 'use client' demarcation line shows you understand where the boundary is. Discussing the trade-off: server components for data-rich, static UI; client components for interactivity—demonstrates practical depth. Also noting that the component code never ships to the browser is a key performance benefit interviewers expect you to know.

One of the most powerful features of server components is the ability to directly fetch data from the server, without needing an API route or a separate data-fetching layer. This eliminates the mental overhead of deciding where data-fetching logic should live and reduces the number of network round-trips required to render a page.

Server Components (default): In the app directory, the default is server components. This means data fetching happens on the server by default, and the result is streamed to the client. Server components can use async/await directly in the component body to fetch data from databases, APIs, or the file system. The key benefit is that the data-fetching logic does not send any JavaScript to the client. The HTML sent to the client includes the rendered result of the data fetch, but the code that fetched the data stays on the server.

Client Components: Mark a component with 'use client' if you need interactivity (event handlers, state, useState/useEffect). Client components can render server data, but the data-fetching logic itself runs on the server. Use client components when you need useState, useEffect, or event handlers.

// Same file, after the server component section
'use client'
import { useState } from 'react'

export function LikeButton() {
  const [liked, setLiked] = useState(false)
  return (
    <button onClick={() => setLiked(!liked)}>
      {liked ? 'Liked' : 'Like'}
    </button>
  )
}

Data Fetching Patterns:

1. Fetch in server component: Best for initial data needed on page load. The fetch runs on the server, and the HTML sent to the client includes the rendered result. This is the primary pattern for content-rich pages.

2. Fetch in client component with Suspense: Use the <Suspense> boundary to show fallback while the async data loads on the client. This pattern is useful when you need client-side state management alongside data fetching.

3. Route handlers: For API-like endpoints, use export const dynamic = 'force-server-only' or export const revalidation for ISR. Route handlers can serve as API endpoints within the app router structure.

Incremental Static Regeneration (ISR): export const revalidate = 60 — re-render the page every 60 seconds when new data arrives. Combines the performance of static sites with the freshness of server rendering. ISR works well with server components because the revalidation happens on the server, and the updated HTML is streamed to the client.

Why direct data fetching matters: In traditional full-stack development, data fetching often requires setting up API routes, handling authentication, and managing CORS. With server components, much of this complexity is reduced. You can fetch data directly where you need it, and the framework handles the server-client boundary. This leads to simpler code, better performance, and fewer moving parts in your application.

Interview framing: When asked about data fetching in the app router, a strong answer explains that server components can fetch data directly using fetch(), database drivers, or async/await. The result is streamed to the client, and no JavaScript is sent for the data-fetching logic. Mentioning ISR via export const revalidate = <seconds> for combining static performance with fresh data demonstrates depth. Also mentioning route handlers as a way to build API endpoints within the app router structure shows you understand the full capabilities of the framework.

When interviewers ask about server components, a strong answer covers three key areas:

1. Default server behavior: Explain that the app directory assumes server components by default, which reduces client JavaScript and enables direct data fetching. This is the fundamental performance optimization of the Next.js app router. The implicit server-side rendering means less JavaScript for the browser to parse and execute, which directly improves time-to-interactive and core web vitals. This is often the first thing interviewers look for when evaluating Next.js knowledge.

2. The 'use client' demarcation line: Mention that 'use client' at the top of a file marks a component as running in the browser, enabling hooks like useState, useEffect, and event handlers. The boundary between server and client is critical—components on one side cannot use features from the other side without the explicit demarcation. This shows you understand the security and performance implications of the boundary. Mentioning that placing 'use client' too broadly defeats the purpose of server components demonstrates deep understanding.

3. Interop and data flow: Server components can import and render client components, combining static, data-rich markup with interactive UI. Data flows from server to client via props and JSX children, not the other way around. This unidirectional data flow ensures that sensitive logic and database queries stay on the server. This is a security best practice and also reduces the attack surface of your application.

Interview quick answers:

• What's the default? — server components
• Why zero JS to client? — faster TTI, better performance
• What can't server components use? — useState, useEffect, DOM APIs
• How do they interop? — server imports and renders client components
• Where's the boundary? — 'use client' line

Typical interview question: "When do you use server components vs. client components?" The answer is: use server components for data-rich, static UI where no interactivity is needed. Use client components when you need state, effects, or event handlers. The key is to keep the majority of the component tree on the server and only mark leaf components that need interactivity with 'use client'. This island architecture pattern optimizes for performance while still providing rich user experiences.

Another common question: "Can server components and client components be in the same file?" The answer is: technically yes, if you use dynamic imports, but it's not recommended. The optimal approach is to keep server and client components in separate files or directories, with a clear boundary between them.

Island architecture pattern: The optimal approach is to keep the majority of the component tree as server components, and only mark leaf components that need interactivity with 'use client'. This minimizes the JavaScript sent to the browser while still providing rich interactivity where needed. This pattern is the cornerstone of Next.js performance optimization and is a topic interviewers expect you to know deeply.

Typical interview scenario: An interviewer asks: "Your page is slow and the bundle is large. What do you do?" A strong answer: "I'd examine which components need interactivity and move them to leaf 'use client' islands, keeping the rest as server components. I'd also review any data-fetching logic to ensure it's running on the server." This shows you have a practical, measurable approach to performance optimization, not just theoretical knowledge.

Island architecture in practice: Many successful Next.js applications follow a pattern where the home page is entirely server-rendered, navigation components have minimal 'use client' at the leaf level, and feature-rich pages (like dashboards or forms) have more 'use client' directives. This balanced approach maximizes performance while still providing rich interactivity where needed.

Measuring the impact: Tools like next build analysis, webpack-bundle-analyzer, and source-map-explorer can help you understand the impact of adding 'use client' directives. A strong answer mentions using these tools to identify components that would benefit from being client-side, and measuring the before/after impact on bundle size and performance metrics.

Why the measurement matters: In performance-critical applications, even small reductions in bundle size can have significant impacts on time-to-interactive and core web vitals. Being able to quantify the impact of architectural decisions (e.g., 'Moving the navigation component to a server component reduced the bundle by 30KB and improved LCP by 100ms') demonstrates you treat performance as a quantifiable system, not just a theoretical concern.