Is Next.js always the right choice? Maybe not if you are strictly self-hosting.
The "Vercel Magic" is real: Vercel abstracts away massive complexity regarding Edge computing and CDN distribution. Replicating this manually on AWS is painful.
We recently kicked off a project betting big on Next.js.
The goal was simple: leverage its powerful caching system and Server-Side Rendering (SSR) for top-tier performance.
However, we had a strict constraint: No Vercel (https://vercel.com/). We had to manage the infrastructure entirely within our own AWS environment.
This turned out to be our biggest bottleneck.
Here is what we learned:
π· The "Vercel Magic" is real: Vercel abstracts away massive complexity regarding Edge computing and CDN distribution. Replicating this manually on AWS is painful.
π· Caching Nightmares: Without the native infrastructure Next.js expects, the caching strategy became our arch-nemesis, causing more bugs than performance gains.
π· The Pivot: To make it work with CloudFront and our rigid infra, we had to strip away the SSR and server caching strategies.
In the end, we essentially turned Next.js into a standard client-side router/renderer functioning almost exactly like a pure React app.
The takeaway? Tools like OpenNext (https://opennext.js.org/) are great, but in a restricted, managed infrastructure, the friction is high. If you can't use the platform designed for the framework (Vercel), simpler might be better.
The takeaway? Tools like OpenNext (https://opennext.js.org/) are great, but in a restricted, managed infrastructure, the friction is high. If you can't use the platform designed for the framework (Vercel), simpler might be better.