Next.js React Framework Interview Preparation Guide

Traditional SSR generates an initial HTML string on the server for the entire component tree, which is then sent to the browser where all component JavaScript must be downloaded, parsed, and hydrated. In contrast, React Server Components do not send their component code or dependencies to the client at all. Instead, RSCs execute on the server and stream a serialized virtual DOM tree (the Flight protocol) to the client. Only components explicitly marked with 'use client' are bundled and hydrated on the browser, resulting in significantly smaller client-side JavaScript bundles and faster Time to Interactive.

You should choose Incremental Static Regeneration (ISR) when your pages contain content that updates periodically—such as blog posts, product catalog pages, or marketing content—where serving slightly stale cached data for a few seconds is acceptable in exchange for lightning-fast TTFT served straight from a CDN edge cache. You should choose Server-Side Rendering (SSR) when every single request requires real-time, user-specific data that cannot be cached, such as an authenticated user dashboard or a live financial trading terminal where stale data poses a business risk.

Server Actions are asynchronous functions executed on the server but invoked from client components. Next.js automatically secures Server Actions against Cross-Site Request Forgery (CSRF) attacks by validating the Origin and Host headers of incoming POST requests against the expected server host. Furthermore, actions use encrypted closures to prevent tampering with function arguments, and sensitive business logic or database credentials remain strictly on the server because the function body never ships to the browser.

Cookies and request headers depend entirely on runtime request properties that cannot be known at build time. Because their values vary per user request, Next.js cannot statically prerender or cache the page response at build time without risking leaking user data across sessions. Consequently, invoking these dynamic APIs signals to the Next.js compiler that the route must be dynamically rendered on the server for every incoming request.

revalidatePath invalidates the cached output of a specific URL path, forcing Next.js to regenerate that page on the next incoming request. In contrast, revalidateTag purges cache entries associated with specific cache tags across multiple routes. This allows you to tag multiple fetch requests—such as fetching user profile data across various pages—and invalidate all of them simultaneously with a single revalidateTag('user-profile') call upon a database mutation.

In the traditional Pages Router, shared layouts were difficult to maintain, often requiring custom wrapper components in _app.js that re-rendered entirely on page navigation. The App Router introduces file-system-based nested layouts (layout.js) where parent layouts persist across child route transitions. When a user navigates between sibling pages within the same layout, the parent layout remains mounted and preserves its React state, while only the inner page segment re-renders and streams over the network.

Hydration mismatches occur when the HTML generated during server-side rendering differs from the initial HTML rendered by the client browser during hydration. This commonly happens when components access browser-only APIs like window, localStorage, or Date.now() during the render pass, producing values on the server that do not match the client. You debug these errors by examining the detailed component stack trace in the browser console during development and ensuring browser-only logic is wrapped in useEffect or executed after client mounting.

Serverless platforms (like Vercel or AWS Lambda) scale automatically to zero, meaning you only pay for actual compute execution time, making low-traffic or spiky workloads extremely cost-effective. However, serverless cold starts can introduce latency spikes, and caching must be carefully orchestrated via CDNs. Traditional persistent Node.js servers (like AWS ECS or Kubernetes) eliminate cold starts and offer predictable long-running execution for heavy data processing, but require manual capacity planning and incur constant idle infrastructure costs.

Turbopack is written in Rust and engineered from the ground up for incremental computation. Unlike Webpack, which often re-evaluates large portions of the dependency graph on file changes, Turbopack maintains a persistent cache of parsed module graphs. When a file changes, Turbopack computes only the minimal necessary updates, resulting in near-instantaneous Hot Module Replacement (HMR) and significantly faster development server startup times, particularly in large enterprise monorepos.

Partial Prerendering leverages React Suspense boundaries within a single route. At build time, Next.js prerenders a static HTML shell for the page—such as headers, navigation bars, and structural wrappers—using cached content. When a user requests the page, the static shell is served instantly. Simultaneously, dynamic components wrapped in Suspense stream over the same HTTP connection as their underlying data resolves, giving users the instant load time of static hosting combined with real-time personalized data.

Placing 'use client' at the root layout forces every single child component in your application tree to be treated as a Client Component. This completely negates the benefits of React Server Components, causing all component code, third-party libraries, and heavy dependencies to be bundled and shipped to the browser. It increases the client JavaScript bundle size, degrades parsing and execution performance, and prevents direct server-side database querying within your component tree.