Comment by SwiftyBug
5 days ago
Im curious about the choice of Next.js for an open source project as Next.js is notoriously painful to deploy to anything other than Vercel.
5 days ago
Im curious about the choice of Next.js for an open source project as Next.js is notoriously painful to deploy to anything other than Vercel.
This isn’t something I’ve found with NextJS, but I also haven’t tried a lot of other, similar frameworks because I’m mostly a backend and SRE person who just learned NextJS so I could throw together pretty UIs to demo my backend ideas, so maybe I’m missing things that are well known among front-end specialists.
My experience is that a basic deployment is very easy—it’s like a ten line Dockerfile to build a distroless nodejs container of the standalone build and if you deploy it, it just works.
Then, as performance demands grow, there’s increasingly more complexity in the efforts that must be taken to squeeze additional performance out of it. An easy win is to host the static resources more efficiently with a static file server or better yet a CDN.
A more complex performance optimization is to implement caching.
At some point you start thinking about how to separate the middleware execution from the app so that it can be hosted in more regions or at the edge.
Vercel provides all of those optimizations for free in terms of operational complexity, and charges a lot for it monetarily, but it’s not all that surprising to me that when I host an application it takes some effort to get performance and feature parity with a dedicated hosting provider for that service, just like how I am not surprised that RDS is a little more complicated, more performant, and more reliable than renting the equivalent EC2 and installing Postgres from the package manager.
Caveat: as a backend dev, I’ve never written anything that relied entirely on NextJS as the server side, so I’m approaching this with a certain amount of baseline complexity already assumed. I’ve not touched NextJS static sites or incremental static regeneration.
Do other frontend frameworks make it much easier to incorporate those performance optimizations? My impression is that it’s not all that hard to deploy NextJS, it’s just hard to manage the complexity of optimizing it to the extent that Vercel’s hosting does.
Next.js is not difficult to deploy on a long-lived server. It’s just a normal Node app.
What’s more painful is deployment to other serverless providers because historically they’ve had to reverse-engineer a few details for more advanced features. This is being fixed now in https://github.com/vercel/next.js/discussions/77740 but that work is ongoing.
The difficulty to deploy Next.js is greatly exaggerated in my opinion. It's mostly if you care about some of the more advanced features, like image optimization and hosting static assets on a different origin it can become difficult, but these are features no Next.js alternative generally provide anyway.
> hosting static assets on a different origin it can become difficult
What's the alternative? Hosting the static assets on the same place as the backend? Usually adding the CORS headers is enough to solve that (on the backend side), the frontend is still just HTML,CSS and JS running from nginx.
Is it common to do a different type of deployment with Next.js? It's a pretty basic deployment scenario (having the frontend on a different origin than the backend it communicates with), so not sure why that'd be so difficult with Next.js compared to basically anything else.
It's the opposite, it's extremely easy to do that with Next.js - pretty much free - but only if you're deploying to Vercel. If you want to host somewhere else then you have to do that semi-manually the same way you would with any other framework.
Same. I've deployed a half dozen or so Next.js apps and it's no more difficult than any other node app unless you're using some of the more advanced features. In fact, if you only need something static and can do SSG then it's far easier than other node apps because all you need is nginx.
Even with the optimizations it's not that difficult in my experience. Not terribly well documented (not worst-in-class either) but not that hard and mostly just works once you have a pipeline up and running. We set ours up about two years ago now and have had to make minor modifications maybe three times since then.
Deploying next is difficult, but IMO that's because deploying anything substantial is difficult. I've had my share of nasty deployment debugging that took days and none of it was due to next. (the biggest offenders I've seen are (1) random open source software no one on my team is an expert on, (2) docker / kubernetes, (3) databases, and (4) integration hell)
It's what v0 and similar tools choose as default.
It’s as easy as deploying any other app that can be Dockerized. Deploying to something like Fargate isn’t _super_ trivial but can be done in <2 hours
Maybe it's difficult to deploy to your platform of choice. Deploying to AWS amplify or deploying using sst is matter of minutes or hour.
I have deployed several next.js projects within an hour (not hours) that were created by different teams. The hour includes settings up DNS, CI/CD using github and deploying to AWS Amplify.
Edit: Why are you down voting it? Is this unbelievable? I have deployed 5/6 next.js projects and none of them are on vercel.