Every site we ship runs a Next.js front-end against a .NET API. The reasoning behind that split, and the trade-offs we accepted for it.
We settled on one stack and use it for nearly everything: a Next.js front-end, a .NET Web API behind it, PostgreSQL underneath, deployed on our own infrastructure behind Cloudflare.
Splitting the front-end from the API is the important decision
The stack matters less than the boundary. The front-end renders; the API owns data and business rules. Nothing else touches the database.
That boundary buys three things. Each side can be hardened, scaled and deployed independently. The API is reusable — the same endpoints serve the website, the admin panel and any future mobile app. And a front-end compromise cannot reach the database, because the front-end holds no credentials to reach it with.
Why Next.js on the front
Server components let us render on the server by default and ship a fraction of the JavaScript a traditional SPA would. For content and commerce sites, that is the difference between passing Core Web Vitals and failing them.
It also removes the SEO argument entirely. Pages arrive as HTML, with metadata, canonical URLs and structured data generated server-side.
Why .NET on the back
Static typing end to end, a mature ORM in EF Core, first-class authentication, and genuinely fast runtime performance. On Windows infrastructure with IIS in front of it, the operational story is boring in the best possible way — and boring infrastructure is what you want at three in the morning.
The trade-off we accepted
Two runtimes means two deployment pipelines, two sets of logs and two things to keep patched. That is real overhead. We accept it because the isolation it buys is worth more than the convenience of a single process — particularly when one server hosts many client sites that must never be able to see each other.
- Next.js
- .NET
- architecture
- performance
