Explain the App Router vs Pages Router SSR model differences. How does React Server Components change the SSR paradigm?

Question

Accepted Answer

The evolution from Pages Router to App Router in Next.js represents a fundamental shift in how Server-Side Rendering (SSR) is approached. Pages Router treats SSR as a page-level concern using getServerSideProps, while App Router integrates SSR at the component level through React Server Components (RSC). This change moves from a 'fetch-on-render' model to a 'render-with-fetch' model, where components can directly access server resources and stream their output progressively to the client, dramatically reducing client-side JavaScript and improving performance. Pages Router SSR: Page-level, monolithic rendering with getServerSideProps running on every request, fetching all data before rendering begins, and sending complete HTML to client App Router SSR: Component-level, granular rendering with Server Components that can fetch data directly and stream progressively, allowing dynamic and static content to coexist in the same route Data fetching location: Pages Router requires data fetching in special functions outside components; App Router allows direct data fetching inside components using async/await Hydration approach: Pages Router hydrates entire pages; App Router selectively hydrates only Client Components, leaving Server Components as pure server output // pages/pokemon/[name].js - Pages Router SSR // Traditional approach: page-level data fetching export async function getServerSideProps({ params }) { // This runs on EVERY request // All data must be fetched before rendering starts const res = await fetch(`https://api.example.com/pokemon/${params.name}`); const data = await res.json(); // Comments would need another API call or client-side fetch // const comments = await fetch(`https://api.example.com/comments/${params.name}`); return { props: { data } }; } export default function PokemonPage({ data }) { // Entire page hydrates on client // All components become interactive, even those without interactions return (

{data.name}

{data.description}

{/* This interactive component ships JS to client */} {/* Comments would need client-side fetch or be part of getServerSideProps */}

); } // Problems: // ✓ Simple but monolithic // ✗ All components hydrate, increasing JS bundle // ✗ Slow data dependencies block rendering // ✗ No streaming - everything waits for slowest API // app/pokemon/[name]/page.tsx - App Router SSR // Component-level approach with streaming // This component runs on the server, no 'use client' directive // It can be async and fetch data directly export default async function PokemonPage({ params }: { params: { name: string } }) { // Direct data fetching inside component // This runs on server, never ships to client const pokemon = await fetch(`https://api.example.com/pokemon/${params.name}`, { // Can use caching strategies per fetch next: { revalidate: 3600 } }).then(r => r.json()); return (

{pokemon.name}

{pokemon.description}

{/* Only this interactive component becomes a Client Component */} {/* Comments can stream in separately, not blocking main content */} Loading comments...

}> ); } // components/LikeButton.tsx 'use client'; // Only this file needs client-side JavaScript export function LikeButton({ pokemonId }: { pokemonId: string }) { const [liked, setLiked] = useState(false); return ( ); } // components/CommentsSection.tsx // Server Component that streams independently async function CommentsSection({ pokemonId }: { pokemonId: string }) { // This fetch doesn't block the main page render const comments = await fetch(`https://api.example.com/comments/${pokemonId}`) .then(r => r.json()); return (

{comments.map(comment => (

{comment.text}

))}

); } React Server Components (RSC) fundamentally redefine the SSR model by introducing a new rendering target. Instead of treating all components as potentially interactive, RSC establishes a default of server-only execution. Components run exclusively on the server, generate a special RSC Payload (a compact binary format containing rendered output and client component references), and never ship JavaScript to the client . This eliminates the traditional trade-off where SSR meant shipping the same component code twice—once for server HTML and again for client hydration. With RSC, only components explicitly marked with 'use client' become part of the client bundle, while the rest remain pure server-rendered output . Zero bundle size for s

Explain the App Router vs Pages Router SSR model differences. How does React Server Components change the SSR paradigm?

App Router replaces Pages Router's page-level SSR (getServerSideProps) with component-level SSR using Server Components, shifting from per-request data fetching to granular, streaming server rendering with selective hydration

Explain the App Router vs Pages Router SSR model differences. How does React Server Components change the SSR paradigm?

App Router replaces Pages Router's page-level SSR (getServerSideProps) with component-level SSR using Server Components, shifting from per-request data fetching to granular, streaming server rendering with selective hydration

Scenario Questions

Follow-up Questions