API Routes in Next.js: When You Don't Need a Separate Backend at All

This site's own contact form (`src/app/api/contact/route.ts`) is a real backend endpoint — server-side validation, rate limiting, an email API call — living in the exact same Next.js codebase as every page component, with no separate Express server or backend deploy involved.

What a route handler actually is

// app/api/contact/route.ts
export async function POST(request: Request) {
  const body = await request.json();
  // validate, rate-limit, call a third-party API — real server-side code,
  // running in a Node.js environment, never shipped to the browser
  return Response.json({ ok: true });
}

A `route.ts` (or `.js`) file inside `app/` exports functions named after HTTP methods — `GET`, `POST`, `PUT`, `DELETE` — and Next.js wires them to that folder's URL automatically, the same file-based convention as page routing. This code runs server-side only; it has access to environment variables, can call other APIs with secret keys, and never ships to the client bundle.

When this is genuinely enough, and when it isn't

For a contact form, a webhook receiver, or a thin proxy to a third-party API, a route handler is a complete, correct backend — no separate service needed. It stops being enough once you need things a serverless-style route handler isn't built for: long-running background jobs, WebSocket connections that need to persist across requests, or a genuinely separate deploy lifecycle from the frontend (a mobile app's backend that a web frontend also happens to consume). At that point, a dedicated backend service is the right call — but for a large share of real projects, especially early on, that point never actually arrives.

Why this matters for a solo or small team

One deploy, one codebase, one set of environment variables to manage — a route handler removes an entire category of "is my frontend's API URL pointing at the right backend environment" class of bugs, because there's only one environment. That operational simplicity is a real, practical reason this pattern shows up constantly in solo and small-team full-stack work, not just a toy convenience.