Next.js Developer Interview Questions

Summary

Next.js is a React framework that adds file-based routing, server rendering (SSR, static generation, streaming), React Server Components, data fetching and caching, API endpoints (Route Handlers), image/font optimization and a production build pipeline.

Longer Answer

Plain React (e.g., a Vite SPA) renders in the browser and leaves routing, SEO, data loading and code splitting to you. Next.js renders on the server by default, sending HTML for fast first paint and SEO, then hydrates interactive parts. With the App Router, components are Server Components unless marked 'use client', which reduces the JavaScript shipped to the browser.

Key Points

• File-system routing (App Router and Pages Router)
• SSR, SSG, ISR and streaming
• React Server Components by default
• Route Handlers for backend endpoints
• Built-in image, font and script optimization

Summary

The App Router (app/ directory, stable since Next.js 13.4) is built on React Server Components with nested layouts, streaming, Server Actions and colocated loading/error UI. The Pages Router (pages/) uses getServerSideProps/getStaticProps and client-rendered page components.

Longer Answer

Both can coexist during migration. App Router concepts: layout.tsx (persistent shared UI), page.tsx (route UI), loading.tsx (Suspense fallback), error.tsx (error boundary), route.ts (API handlers), and async Server Components that fetch data directly. Navigation hooks come from next/navigation instead of next/router. New projects should use the App Router.

Key Points

• App Router: RSC, nested layouts, streaming, Server Actions
• Pages Router: getServerSideProps/getStaticProps
• Can coexist for incremental migration
• Different router hooks (next/navigation vs next/router)

Comparison / Tradeoffs

Summary

Server Components render only on the server: they can be async, access databases and secrets directly, and send no JavaScript for themselves to the browser. Client Components (marked with 'use client') render on the server for the initial HTML and then hydrate in the browser, so they can use state, effects, event handlers and browser APIs.

Longer Answer

In the App Router, everything is a Server Component by default. 'use client' marks a boundary: that module and everything it imports become part of the client bundle. Server Components can render Client Components and pass them serializable props (or other Server Components as children). Client Components can't import Server Components directly, but can receive them as props.

Code Example

// app/products/page.tsx (Server Component)
import { AddToCart } from "./add-to-cart";

export default async function ProductsPage() {
  const products = await db.product.findMany(); // runs on the server only
  return (
    <ul>
      {products.map((p) => (
        <li key={p.id}>
          {p.name} <AddToCart productId={p.id} />
        </li>
      ))}
    </ul>
  );
}

// app/products/add-to-cart.tsx
"use client";
import { useState } from "react";

export function AddToCart({ productId }: { productId: string }) {
  const [added, setAdded] = useState(false);
  return <button onClick={() => setAdded(true)}>{added ? "Added" : "Add to cart"}</button>;
}

Key Points

• Server by default in app/
• 'use client' marks a client boundary
• Server: async, direct data access, zero JS
• Client: hooks, events, browser APIs
• Props crossing the boundary must be serializable

Summary

page.tsx defines a route's UI; layout.tsx wraps child segments and persists across navigation; loading.tsx is an automatic Suspense fallback; error.tsx is an error boundary (must be a Client Component); not-found.tsx renders for notFound(); template.tsx is like a layout but remounts on navigation; route.ts defines HTTP handlers.

Longer Answer

Folders define URL segments, and only folders with page.tsx or route.ts are publicly routable, so you can colocate components. global-error.tsx catches errors in the root layout. Layouts don't re-render on navigation between child pages, which preserves state.

Key Points

• Folders = segments; page/route make them routable
• Layouts persist, templates remount
• loading.tsx → Suspense
• error.tsx must be 'use client'

Summary

Server Components can be async and fetch data directly with fetch or any database/ORM client. Next.js adds caching and revalidation options on top: fetch(url, { next: { revalidate: 60, tags: ['posts'] } }), segment-level export const revalidate, and (in newer versions) the 'use cache' directive.

Longer Answer

Fetch data where it's needed: identical fetch calls during one render are deduplicated (request memoization), and you can wrap non-fetch data functions in React's cache() for the same effect. Avoid waterfalls by starting independent requests in parallel (Promise.all) and streaming slower parts behind <Suspense>. Client-side fetching (SWR, TanStack Query) is still useful for highly interactive or user-specific live data.

Code Example

export default async function Dashboard() {
  const [user, stats] = await Promise.all([
    getUser(),                                                        // React cache()-wrapped DB call
    fetch("https://api.example.com/stats", { next: { revalidate: 60, tags: ["stats"] } }).then((r) => r.json()),
  ]);
  return <Overview user={user} stats={stats} />;
}

Key Points

• Async Server Components fetch directly
• Request memoization dedupes identical fetches
• revalidate and tags control freshness
• Parallelize with Promise.all; stream with Suspense

Summary

Next.js 15 made caching opt-in: fetch requests are no longer cached by default, GET Route Handlers are not cached by default, and the client Router Cache no longer reuses page segments (stale time 0) on navigation.

Longer Answer

In Next.js 14, fetch defaulted to force-cache, which surprised many developers with stale data. In 15 you explicitly opt in with cache: 'force-cache', next: { revalidate }, or segment config like export const dynamic = 'force-static'. Pages without dynamic APIs can still be statically pre-rendered at build time. Next.js 15 also made request APIs (cookies(), headers(), params, searchParams) asynchronous.

Key Points

• fetch uncached by default in 15
• GET Route Handlers uncached by default
• Router Cache staleTime 0 for pages
• Async cookies(), headers(), params

Summary

SSG pre-renders pages at build time; ISR (Incremental Static Regeneration) re-generates static pages in the background after a revalidation period or on demand; SSR renders on every request; CSR renders in the browser after loading JavaScript.

Longer Answer

App Router mapping: a route is static by default if it uses no dynamic APIs (SSG). export const revalidate = 60 or fetch(..., { next: { revalidate: 60 } }) gives ISR. Using cookies()/headers()/uncached data makes it dynamic (SSR). Client Components with client-side fetching are CSR. Choose based on data freshness and personalization needs.

Key Points

• SSG: build time, fastest
• ISR: static + periodic/on-demand refresh
• SSR: per request, personalized
• CSR: browser rendering for interactivity

Comparison / Tradeoffs

Summary

Server Actions are async functions marked with 'use server' that run on the server and can be called from forms (<form action={createPost}>) or Client Components. Next.js handles the network request, and the action can revalidate caches and redirect.

Longer Answer

They remove the need for separate API routes for many mutations and work with progressive enhancement (forms submit before JS loads). Use useActionState (React 19) for pending state and returned errors, and useFormStatus for submit button state. Security: every Server Action is a public HTTP endpoint, so always validate input (e.g., with Zod) and check authentication/authorization inside the action.

Code Example

// app/posts/actions.ts
"use server";
import { z } from "zod";
import { revalidatePath } from "next/cache";
import { redirect } from "next/navigation";

const PostSchema = z.object({ title: z.string().min(3), body: z.string().min(10) });

export async function createPost(prevState: unknown, formData: FormData) {
  const session = await auth();
  if (!session) return { error: "Not signed in" };

  const parsed = PostSchema.safeParse(Object.fromEntries(formData));
  if (!parsed.success) return { error: parsed.error.flatten().fieldErrors };

  const post = await db.post.create({ data: { ...parsed.data, authorId: session.user.id } });
  revalidatePath("/posts");
  redirect(`/posts/${post.id}`);
}

Key Points

• 'use server' functions callable from forms/clients
• Revalidate with revalidatePath/revalidateTag
• useActionState / useFormStatus for UX
• Treat as public endpoints: validate and authorize

Summary

next.config headers, redirects and rewrites apply; the proxy (middleware.ts before Next.js 16) runs for matched paths and may redirect, rewrite or respond; routing serves static assets directly or matches an app route; server components render on the server (fetching data, using caches where configured) to HTML for the first load or an RSC payload for client navigations; route handlers and server actions handle API requests and mutations; in the browser, client components hydrate and links prefetch routes.

Longer Answer

Consequences: a proxy without a matcher runs for every asset and prefetch, so keep it cheap and authorise near the data (server components, route handlers, server actions). Layouts persist across client navigations, so they don't re-run for every page change.

Key Points

• Config redirects/rewrites → proxy → routing.
• Server components render on the server.
• Route handlers and server actions for APIs and mutations.
• Client components hydrate; links prefetch.

Deep dive: Request Lifecycle course: Next.js: Proxy (Middleware), Rendering and Caching

Summary

[slug] matches one segment, [...slug] matches one or more segments (array), and [[...slug]] also matches the parent path with no segments. Params arrive in the page's params prop.

Longer Answer

In Next.js 15+, params and searchParams are Promises in Server Components, so you await params. Use generateStaticParams to pre-render known params at build time.

Code Example

// app/blog/[slug]/page.tsx
export default async function Post({ params }: { params: Promise<{ slug: string }> }) {
  const { slug } = await params;
  const post = await getPost(slug);
  if (!post) notFound();
  return <article>{post.title}</article>;
}

export async function generateStaticParams() {
  const posts = await getAllPosts();
  return posts.map((p) => ({ slug: p.slug }));
}

Key Points

• [id] single segment
• [...parts] one or more
• [[...parts]] zero or more
• params is a Promise in Next 15+

Summary

The server sends HTML in chunks: the shell (layout plus fast parts) is sent immediately, and slower components wrapped in <Suspense fallback={...}> stream in when their data resolves, without blocking the whole page.

Longer Answer

loading.tsx automatically wraps a page in Suspense. Place Suspense boundaries around slow, independent sections (recommendations, comments) to improve Time To First Byte and First Contentful Paint. Streaming works with SSR; SEO still gets the full HTML, since crawlers receive the completed stream.

Code Example

import { Suspense } from "react";

export default function ProductPage({ params }: { params: Promise<{ id: string }> }) {
  return (
    <>
      <ProductDetails params={params} />
      <Suspense fallback={<p>Loading reviews…</p>}>
        <Reviews params={params} /> {/* slow async server component */}
      </Suspense>
    </>
  );
}

Key Points

• Shell first, slow parts stream later
• loading.tsx = route-level Suspense
• Granular <Suspense> boundaries
• Improves TTFB/FCP

Summary

Route Handlers (app/api/.../route.ts) export functions named after HTTP methods (GET, POST, ...) using Web Request/Response APIs. Use them for public REST endpoints, webhooks, third-party callbacks, file downloads and mobile clients; use Server Actions for mutations triggered from your own UI.

Longer Answer

Route Handlers support streaming responses, NextResponse.json(), cookies and headers, and can run on Node or Edge runtimes. In Next.js 15+, GET handlers aren't cached by default (export const dynamic = 'force-static' opts in).

Code Example

// app/api/webhooks/stripe/route.ts
import { NextResponse } from "next/server";

export async function POST(req: Request) {
  const body = await req.text();
  const sig = req.headers.get("stripe-signature")!;
  const event = stripe.webhooks.constructEvent(body, sig, process.env.STRIPE_WEBHOOK_SECRET!);
  await handleEvent(event);
  return NextResponse.json({ received: true });
}

Key Points

• Export GET, POST, etc. from route.ts
• Web Request/Response APIs
• Webhooks, public APIs, mobile clients
• Server Actions for UI mutations

Summary

Middleware (middleware.ts, called proxy.ts from Next.js 16) runs before a request is matched to a route, so it can rewrite, redirect, set headers/cookies or return early. It's good for lightweight concerns like locale redirects, A/B rewrites, and coarse auth redirects.

Longer Answer

It runs for every matched request, so keep it fast and limit it with config.matcher. Don't rely on it as the only authorization layer: check auth again in Server Components, Server Actions and Route Handlers close to the data. A 2025 vulnerability (CVE-2025-29927) let attackers bypass middleware via a crafted internal header, which shows why defense in depth matters.

Code Example

// middleware.ts (proxy.ts in Next.js 16)
import { NextResponse, type NextRequest } from "next/server";

export function middleware(req: NextRequest) {
  const hasSession = req.cookies.has("session");
  if (!hasSession && req.nextUrl.pathname.startsWith("/dashboard")) {
    return NextResponse.redirect(new URL("/login", req.url));
  }
  return NextResponse.next();
}

export const config = { matcher: ["/dashboard/:path*"] };

Key Points

• Runs before routing; rewrite/redirect/headers
• Use matcher to scope it
• Keep it fast and light
• Not the only auth check (defense in depth)

Deep dive: Request Lifecycle course: Next.js: Proxy (Middleware), Rendering and Caching

Summary

revalidatePath('/posts') invalidates cached data and rendered output for a path; revalidateTag('posts') invalidates all cached fetches/entries tagged posts. Both are called from Server Actions or Route Handlers after mutations or webhooks.

Longer Answer

Tag-based invalidation is more precise: tag the fetch (next: { tags: ['post:42'] }) and invalidate exactly what changed. On-demand revalidation via a webhook (e.g., from a CMS) keeps static pages fresh without short time-based intervals. Recent versions also add updateTag for read-your-own-writes semantics within Server Actions.

Key Points

• Path-based vs tag-based invalidation
• Call after mutations or CMS webhooks
• Tag fetches precisely
• Combine with time-based revalidate

Summary

Export a static metadata object or an async generateMetadata() from layouts and pages; Next.js merges them down the tree and renders <title>, meta descriptions, Open Graph and Twitter tags. Use sitemap.ts, robots.ts and opengraph-image.tsx file conventions for the rest.

Longer Answer

generateMetadata can fetch data (deduplicated with the page's fetch). Use title.template in the root layout ('%s | Acme'). Server rendering means crawlers receive full HTML. Add JSON-LD structured data via a <script type='application/ld+json'> in the page.

Code Example

export async function generateMetadata({ params }: { params: Promise<{ slug: string }> }) {
  const post = await getPost((await params).slug);
  return {
    title: post.title,
    description: post.excerpt,
    openGraph: { images: [post.coverUrl] },
  };
}

Key Points

• metadata / generateMetadata
• Merged from layouts to pages
• sitemap.ts, robots.ts, OG image routes
• Title templates

Summary

<Image> automatically resizes, optimizes and serves modern formats (WebP/AVIF), lazy-loads images by default, prevents layout shift by requiring dimensions (or fill), and generates responsive srcsets.

Longer Answer

Remote images need images.remotePatterns configured. Use priority (or fetchPriority='high') for the Largest Contentful Paint image, sizes for responsive layouts, and placeholder='blur' for nicer loading. Self-hosting needs the optimization server (or a custom loader / CDN).

Key Points

• Automatic resizing and modern formats
• Lazy loading by default
• Width/height or fill prevents CLS
• priority for the LCP image
• remotePatterns for external hosts

Summary

Variables in .env* files are available on the server via process.env. Only variables prefixed with NEXT_PUBLIC_ are inlined into the client bundle at build time, so never put secrets in NEXT_PUBLIC_ variables.

Longer Answer

NEXT_PUBLIC_ values are baked in at build time, so changing them requires a rebuild (unless you read them at runtime on the server and pass them down). Use the server-only package to make modules containing secrets fail the build if imported into client code.

Key Points

• process.env on the server
• NEXT_PUBLIC_* inlined in client bundle at build
• Never expose secrets with that prefix
• server-only guards secret modules

Summary

Use a library such as Auth.js (NextAuth v5), Clerk, Better Auth or a custom session system: store sessions in HttpOnly cookies, read the session in Server Components/Actions/Route Handlers via cookies() or the library's auth(), and protect routes with server-side checks (optionally with middleware redirects).

Longer Answer

Centralize authorization in a data access layer (DAL) that verifies the session before returning data, so every page and action goes through it. Don't rely only on hiding UI or on middleware. Use secure, SameSite cookies, and for credentials auth hash passwords properly.

Key Points

• Session in HttpOnly cookies
• Check auth in server code near data access
• Data Access Layer pattern
• Middleware only for coarse redirects

Summary

Hydration errors occur when the HTML rendered on the server differs from what React renders on the client's first pass, e.g. from using Date.now(), Math.random(), window/localStorage, locale-dependent formatting, or invalid HTML nesting.

Longer Answer

Fixes: render browser-only values in useEffect after mount, use dynamic(() => import(...), { ssr: false }) from a Client Component for browser-only components, pass deterministic data from the server, fix invalid nesting (e.g., <div> inside <p>), and use suppressHydrationWarning only for unavoidable cases like timestamps. Browser extensions modifying the DOM can also trigger them.

Key Points

• Server and client output must match
• Defer browser-only values to effects
• dynamic(..., { ssr: false })
• Fix invalid HTML nesting

Summary

Minimize client JavaScript (keep components on the server, push 'use client' down the tree), optimize the LCP image with next/image priority, use next/font, stream slow content with Suspense, avoid layout shift with sized media, and defer third-party scripts with next/script strategies.

Longer Answer

Analyze bundles with @next/bundle-analyzer, lazy-load heavy client components with next/dynamic, and avoid large client-side libraries for things the server can do. Measure with Lighthouse, Web Vitals reporting (useReportWebVitals) and real-user monitoring (INP, LCP, CLS).

Key Points

• Less client JS via Server Components
• LCP image priority
• Stream slow sections
• Bundle analysis + dynamic imports
• Measure INP/LCP/CLS in the field

Summary

getServerSideProps runs on every request and passes props to the page (SSR); getStaticProps runs at build time (with optional revalidate for ISR); getStaticPaths lists dynamic paths to pre-render, with fallback controlling unknown paths.

Longer Answer

fallback: false 404s unknown paths, true serves a fallback UI then renders, and 'blocking' renders on first request like SSR, then caches. These functions only run on the server, so they can access secrets. In the App Router, async Server Components replace them.

Key Points

• getServerSideProps: per request
• getStaticProps + revalidate: SSG/ISR
• getStaticPaths + fallback modes
• Replaced by async Server Components in App Router