Mapping Pages Router APIs to App Router Equivalents

The 30-Second Interview Answer

Migrating from Pages Router to App Router involves direct API mapping: getServerSideProps maps to async Server Components; getStaticProps maps to async fetch or "use cache"; getStaticPaths maps to generateStaticParams; next/head maps to generateMetadata; and API routes (pages/api) map to Route Handlers (route.ts).

Learning Objectives

Map legacy Pages Router lifecycle methods to App Router primitives.

Migrate next/head tags to Metadata API and generateMetadata.

Transform pages/api/*.ts handlers into Web-standard route.ts files.

Identify breaking differences in request and response objects.

Prerequisites & Background Knowledge

Pages Router fundamentalsApp Router architectureHTTP Request/Response standards

Why Interviewers Care

Standard practical migration question asked in senior interviews evaluating real-world refactoring capability.

The Challenge

Construct a comprehensive mapping table between Pages Router APIs and their modern App Router equivalents. Walk through refactoring a legacy dynamic page with getStaticProps and next/head into App Router.

Code Architecture & Implementation

1/*
2┌──────────────────────────────┬──────────────────────────────────────────┐
3│ PAGES ROUTER API             │ APP ROUTER EQUIVALENT                    │
4├──────────────────────────────┼──────────────────────────────────────────┤
5│ getServerSideProps           │ async Server Component (direct DB/fetch) │
6│ getStaticProps               │ async Server Component + static/cache    │
7│ getStaticPaths               │ generateStaticParams()                   │
8│ next/head (<Head>)           │ export const metadata / generateMetadata │
9│ pages/api/[...].ts           │ app/api/[...]/route.ts (GET/POST/etc)    │
10│ next/router (useRouter)      │ next/navigation (useRouter, usePathname) │
11│ _app.tsx + _document.tsx     │ app/layout.tsx                           │
12│ Custom getLayout pattern     │ Nested layout.tsx files                  │
13│ fallback: 'blocking'         │ export const dynamicParams = true        │
14└──────────────────────────────┴──────────────────────────────────────────┘
15*/

Architectural Explanation

The migration from Pages Router to App Router simplifies the mental model. Instead of wrapping everything in specialized framework lifecycle hooks (getStaticProps, getServerSideProps), Server Components use native JavaScript async/await. Route Handlers replace Express-like (req: NextApiRequest, res: NextApiResponse) callbacks with standard Web API Request and Response objects, making code more portable across runtimes.

Common Mistakes & Anti-Patterns

Importing `useRouter` from `next/router` inside the `app` directory, causing a runtime crash.

Importing `next/head` in Server Components instead of using the Metadata API.

Attempting to export `getServerSideProps` from an App Router page file.

Interview Follow-Up Traps

The interviewer asks: "Can you still access res.status(200).json(...) in Route Handlers?" No! In App Router `route.ts`, you return `NextResponse.json(...)` or a standard `new Response(...)`.

Frequently Asked Questions

What happens if you have both pages/blog.tsx and app/blog/page.tsx?

App Router takes priority, but Next.js will print a warning about conflicting routes.

How do you migrate pages/api routes with bodyParser disabled?

Route Handlers do not parse bodies automatically; call `await req.json()`, `await req.formData()`, or `await req.arrayBuffer()` directly.

Is Pages Router deprecated?

No. Pages Router is in maintenance mode and supported for existing codebases, but new features target App Router.

Custom _app.js and _document.js Lifecycle Incremental Dual-Router Coexistence in Production