Pages Router legacy knowledge

Pages Router uses the `pages/` directory: files map to routes, and data APIs (`getServerSideProps`, `getStaticProps`, `getStaticPaths`) run at build or request time. API routes live under `pages/api`.

| API | When it runs | Typical use | |-----|--------------|-------------| | getStaticProps | Build | Stable marketing pages | | getServerSideProps | Each request | Personalized dashboards | | getStaticPaths | Build | Dynamic SSG paths |

On interviews: compare Pages data APIs to App Router server fetching and explain migration trade-offs — colocated loaders versus component-level fetch, and `_app`/`_document` versus root layouts.

Common pitfalls: copying Pages patterns into App Router verbatim, keeping dual routers indefinitely, and assuming interviewers only care about App Router in brownfield teams.

The trade-off is migration cost versus maintaining two mental models.

Checklist:

• Map pages file to URL rules.
• Know SSR/SSG hooks and API routes.
• Explain migration boundaries to App Router.
• Name legacy constraints in existing products.