Next.js App Router route handlers are just functions — GET, POST, whatever you export. That's the whole appeal: no framework, no ceremony, straight to the Web Request/Response APIs. It's also exactly where the pain starts once an API grows past two or three endpoints. This post builds the same small Post resource twice — once with plain route handlers, once with nextjs-nestapi — and compares what actually changed.

Wiring up app.ts, the catch-all route, and tsconfig.json's decorator flags by hand is only a few minutes of work — but it's a few minutes you'll repeat on every new project or feature. The nextjs-nestapi CLI does it for you.

If you're already annotating controllers with @Controller, @Get/@Post, and @Body(DtoClass), you've already written most of what an OpenAPI document needs. This post shows how nextjs-nestapi turns that into a live spec and a Swagger UI, with no separate documentation step to keep in sync.

Next.js App Router route handlers are fast and simple — and that simplicity starts to hurt once an API grows past a handful of endpoints. Every route is its own file, request parsing is manual, and there's no shared structure for organizing controllers, validating input, or documenting what you've built.

NestJS solves exactly this with controllers, decorators, and DTOs — but pulling in a full Nest runtime (modules, a DI container, its own HTTP adapter) inside a Next.js app is a lot of machinery for what is usually just "organize my API routes."

nextjs-nestapi is the middle ground.