Meanwhile on both platforms, it is either Go or WebAssembly for serverless compiled code, instead of exposing the Lambda infrastructure they rely on.
Talk about openness.
Netlify deploys hundreds of thousands of Next.js sites – here's what challenging
21–28 of 28 posts
Re: Netlify deploys hundreds of thousands of Next.js sites – here's what challenging
#22> Here, “a Node.js server” refers to one Node.js server. A single, unique instance of a Node.js server (with or without Docker) with no horizontal scaling and no zero-downtime deploys is not a viable deployment strategy for serious projects. Ah, the penny drops. The idea that you can’t run a traditional server and must rely on serverless vendor if you’re “serious”, and that NextJs is not convenient to Netlify, is at…
> Ah, the penny drops. The idea that you can’t run a traditional server and must rely on serverless vendor if you’re “serious”
That's not at all how you should read this. They later on give an example of exactly what kinds of problems you'll run into once you start needing to horizontally scale you Next.js servers (e.g. as pods in k8s, which is not serverless):
> The issue of stale data is trickier than it seems. For example, as each node has its own cache, if you use revalidatePath in your server action or route handler code, that code would run on just one of your nodes that happens to process that action/route, and only purge the cache for that node.
Seeing as a Node.js server running Next.js serving SSR or ISR (otherwise you'd just serve static files, which I personally prefer) is not known to have the greatest performance, you will quickly run into the need of needing to scale up your application once you hit any meaningful amount of traffic.
You can then try to keep scaling vertically to avoid the horizontal pains, but even that has limits seeing as Node.js is single-threaded, and will run into issues with the templating part of stringing together HTML simply taking too long (that is, compute will always block, only I/O can be yielded).
The common solution for this in Python, Ruby, and JS/Node.js is to run more instances of your program. Could be on the same machine still, but voila! you are now in horizontal scaling land, and will run into the cache issues mentioned above.
There was not really anything in the article that should have lead you to believe that this was a "serverless only" issue, so I think the bashing against Netlify here is quite unwarranted.
Re: Netlify deploys hundreds of thousands of Next.js sites – here's what challenging
#23> Here, “a Node.js server” refers to one Node.js server. A single, unique instance of a Node.js server (with or without Docker) with no horizontal scaling and no zero-downtime deploys is not a viable deployment strategy for serious projects. Ah, the penny drops. The idea that you can’t run a traditional server and must rely on serverless vendor if you’re “serious”, and that NextJs is not convenient to Netlify, is at…
> suggesting that side stepping lock in altogether by simplifying down to traditional techniques is not “serious” makes me bristle a little This is a strawman. You're misinterpreting the word "serious". They are using it to mean scalable, not about unimportance/ability. At some point in the scaling process, it will be more effective to scale to another machine than stay on a single one at which point you need a lot o…
> Essentially, the whole point of the article is that despite being "open source" you cannot run next.js at scale yourself without a massive investment of your own.
I don't know about that. Asking a service provider to provide an implementation for a cache interface isn't a "massive investment". It's an investment sure, but it's the type of investment that seems should be customizable per provider depending on their needs, technologies they want to bet on, etc. It seems to me the problem with Netlify isn't comfortable putting in the investment to have a NextJS specific cache service. It's understandable considering they don't control the framework and to them it's just another option, so they don't want to invest in it too much.
Re: Netlify deploys hundreds of thousands of Next.js sites – here's what challenging
#24> Here, “a Node.js server” refers to one Node.js server. A single, unique instance of a Node.js server (with or without Docker) with no horizontal scaling and no zero-downtime deploys is not a viable deployment strategy for serious projects. Ah, the penny drops. The idea that you can’t run a traditional server and must rely on serverless vendor if you’re “serious”, and that NextJs is not convenient to Netlify, is at…
> Ah, the penny drops. The idea that you can’t run a traditional server and must rely on serverless vendor if you’re “serious” That's not at all how you should read this. They later on give an example of exactly what kinds of problems you'll run into once you start needing to horizontally scale you Next.js servers (e.g. as pods in k8s, which is not serverless): > The issue of stale data is trickier than it seems. For…
> (e.g. as pods in k8s, which is not serverless):
> There was not really anything in the article that should have lead you to believe that this was a "serverless only" issue, so I think the bashing against Netlify here is quite unwarranted.
It's not because you can use an external cache like Redis[1]. You can scale to hundreds of instances with an external redis cache and you'll be fine. The problem is that you can't operate on Netlify scale with a simple implementation like that. Netlify can't afford running a redis instance for every NextJS application without significantly cutting into their margins (not just from compute cost, but running and managing millions of redis instances at scale won't work).
Clearly Vercel has their own in-house cache service that they have priced in their model. Netlify could run a redis instance per application, though more realistically it needs its own implementation of a multi-tenant caching service that is secure, can scale, cost effective, and fits their operational model. They are not willing to invest in that.
[1] https://github.com/vercel/next.js/tree/canary/examples/cache...
Re: Netlify deploys hundreds of thousands of Next.js sites – here's what challenging
#25Earlier quoted context omitted.
> suggesting that side stepping lock in altogether by simplifying down to traditional techniques is not “serious” makes me bristle a little This is a strawman. You're misinterpreting the word "serious". They are using it to mean scalable, not about unimportance/ability. At some point in the scaling process, it will be more effective to scale to another machine than stay on a single one at which point you need a lot o…
> Essentially, the whole point of the article is that despite being "open source" you cannot run next.js at scale yourself without a massive investment of your own. I don't know about that. Asking a service provider to provide an implementation for a cache interface isn't a "massive investment". It's an investment sure, but it's the type of investment that seems should be customizable per provider depending on their…
(disclaimer: Netlify employee)
The big challenge with the cache interface atm is not using Redis (personally, I love Redis). It's that this interface is far from being a straightforward GET/SET/DELETE. Rather, you need to learn the default implementation and all its nuances (for different payload types), and duplicate/transform all the logic.
The division of labor between what the framework does and what the platform developers (or any other developer working on a high-scale/high-availability deployment) need to do, has to be fixed. If this happens - plus better docs - you should be able to "just use" Redis.
Re: Netlify deploys hundreds of thousands of Next.js sites – here's what challenging
#26Earlier quoted context omitted.
> Ah, the penny drops. The idea that you can’t run a traditional server and must rely on serverless vendor if you’re “serious” That's not at all how you should read this. They later on give an example of exactly what kinds of problems you'll run into once you start needing to horizontally scale you Next.js servers (e.g. as pods in k8s, which is not serverless): > The issue of stale data is trickier than it seems. For…
> (e.g. as pods in k8s, which is not serverless): > There was not really anything in the article that should have lead you to believe that this was a "serverless only" issue, so I think the bashing against Netlify here is quite unwarranted. It's not because you can use an external cache like Redis[1]. You can scale to hundreds of instances with an external redis cache and you'll be fine. The problem is that you can't…
Interesting and definitely something platforms must take into consideration.
Now back to the post, implementing custom cache is not something Netlify is strongly complaining about. They are mostly asking for some documentation with rather stable APIs. Other Frameworks seems to provide that.
Re: Netlify deploys hundreds of thousands of Next.js sites – here's what challenging
#27Earlier quoted context omitted.
> Ah, the penny drops. The idea that you can’t run a traditional server and must rely on serverless vendor if you’re “serious” That's not at all how you should read this. They later on give an example of exactly what kinds of problems you'll run into once you start needing to horizontally scale you Next.js servers (e.g. as pods in k8s, which is not serverless): > The issue of stale data is trickier than it seems. For…
> (e.g. as pods in k8s, which is not serverless): > There was not really anything in the article that should have lead you to believe that this was a "serverless only" issue, so I think the bashing against Netlify here is quite unwarranted. It's not because you can use an external cache like Redis[1]. You can scale to hundreds of instances with an external redis cache and you'll be fine. The problem is that you can't…
> Netlify could run a redis instance per application, though more realistically it needs its own implementation of a multi-tenant caching service that is secure, can scale, cost effective, and fits their operational model. They are not willing to invest in that.
But they have done that, as they say in the post.
Disclosure: used to work at Netlify, now work at Astro
Re: Netlify deploys hundreds of thousands of Next.js sites – here's what challenging
#28Earlier quoted context omitted.
Thank you for clarifying! There is a open source cache adapter but it does not support NextJS 15 at the moment.
Ooh, interesting. We didn't know about this. Is this it? https://github.com/caching-tools/next-shared-cache/tree/cana...
yes, there is even the official example here https://github.com/vercel/next.js/tree/canary/examples/cache...
but it does not work because of NextJS 15.
I changed the example to point to latest NextJs 14 and fixed some cache-handler bugs it works fine, and I deploy it successfully with DollarDeploy to DO VPS https://github.com/huksley/next-cache-handler