Next.js Development

We have shipped the App Router in production since it stabilised, and we have also had to un-ship it once. Both experiences inform how we build. What follows is what we actually do, not what the marketing site says.

Server Components are a data-fetching decision, not a styling one

The default in every project we start is a React Server Component that reads from the database or an internal API, renders to HTML on the server, and ships no JavaScript for itself. Client components are introduced deliberately, at the leaves — a date picker, a chart, a cart drawer — and they are the exception we justify in review, not the default we drift into. The practical effect is a first-load JS budget we can hold under 90 KB gzipped on a content route, against the 300 KB+ that a conventional React SPA of the same surface area ships before it renders a single pixel.

Server Actions replaced most of our API layer

For product surfaces where the Next.js app is the only consumer, we write mutations as Server Actions with Zod validation at the boundary and revalidateTag() for cache invalidation. That deletes an entire tier of hand-written route handlers, request DTOs and client fetch wrappers. We do not do this when a mobile app or a third party also needs the same operation — then it is a real versioned REST or tRPC endpoint, and the Server Action, if it exists at all, calls it. Choosing wrong here is the most common architectural mistake we are asked to clean up.

Caching is the part that bites

The Next.js cache is four caches wearing a trench coat: the request memo, the Data Cache, the Full Route Cache and the client Router Cache. Most "why is my page stale" incidents are someone reasoning about one of them while a different one is serving. We put every fetch into an explicit tag namespace on day one, keep a single module that owns revalidation, and treat an untagged fetch as a review failure. ISR with on-demand revalidation from the CMS webhook then gives us static-file latency with a publish-to-live time in the low seconds.

Rendering strategy, per route, written down

Marketing and content routes are statically generated and revalidated on publish. Logged-in dashboard routes are dynamic and streamed, with Suspense boundaries around anything that touches a slow upstream so the shell paints immediately. Partial Prerendering, where the static shell ships instantly and the personalised holes stream in, is the direction we take when a route is genuinely both. We record the choice per route segment in the repo, because the alternative is a codebase where nobody can say why a page is slow.

The boring infrastructure that actually decides your bill

Next.js will run happily on Vercel, and for a marketing site it is worth every rupee. For an application with heavy traffic and long-running server work, the economics change fast, and we will tell you so. We deploy Next.js in a container on your own infrastructure — AWS ECS, Fly, Hetzner, whatever fits — behind a CDN, with Redis holding the Data Cache so multiple instances share it. The same app, the same code, a materially different invoice at the end of the month.