Next.js Development

We have used the App Router in real projects since it became stable. We have also had to remove it once. Both taught us how to build. Here is what we really do, not what the marketing site says.

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

In every project we start, the default is a React Server Component. It reads from the database or an internal API, builds the HTML on the server, and sends no JavaScript of its own. We add Client components on purpose, only at the small end pieces — a date picker, a chart, a cart drawer. They are the exception we must explain in review, not something we drift into. The result is a first-load JS limit that we can keep under 90 KB gzipped on a content page. A normal React SPA of the same size sends 300 KB+ before it shows a single pixel.

Server Actions replaced most of our API layer

When the Next.js app is the only user of the data, we write data changes as Server Actions. We check the data with Zod at the edge, and we use revalidateTag() to clear the cache. That removes a whole layer of hand-written route handlers, request DTOs and client fetch wrappers. We do not do this when a mobile app or another company also needs the same action. Then we build a proper versioned REST or tRPC endpoint. The Server Action, if there is one, just calls it. Choosing wrong here is the most common design mistake we are asked to fix.

Caching is the part that bites

The Next.js cache is really four caches in one: the request memo, the Data Cache, the Full Route Cache and the client Router Cache. Most "why is my page stale" problems happen when someone thinks about one cache while a different one is serving the page. On day one we put every fetch under a clear tag name. One single module owns the refreshing. We treat a fetch with no tag as a failed review. Then ISR, refreshed on demand by the CMS webhook, gives us the speed of static files and a publish-to-live time of a few seconds.

Rendering strategy, per route, written down

Marketing and content pages are built ahead of time and refreshed when you publish. Logged-in dashboard pages are built live and streamed. We put Suspense around anything that waits on a slow system, so the page frame shows at once. Partial Prerendering sends the fixed frame instantly and streams in the personal parts. We use it when a page is truly both. We write down the choice for each route in the repo. Without that, nobody can say why a page is slow.

The boring infrastructure that actually decides your bill

Next.js runs well on Vercel, and for a marketing site it is worth every rupee. For an app with heavy traffic and long server jobs, the cost changes fast, and we will tell you so. We put Next.js in a container on your own servers — AWS ECS, Fly, Hetzner, whatever fits — behind a CDN. Redis holds the Data Cache so several copies of the app share it. Same app, same code, a very different invoice at the end of the month.