6 ms·

Netlify deploys hundreds of thousands of Next.js sites – here's what challenging

89 points by serhalp 1y ago

deleted 1y ago
[deleted]
pavel_lishin 1y ago
I wonder if this blog post was prompted by this: https://news.ycombinator.com/item?id=43481295 https://news.ycombinator.com/item?id=43481295
- addandsubtract 1y ago
  100%. The OP said he works for Netlify and this seems like a verbatim repost of theirs.
huksley 1y ago
"Fortunately, thanks to Vercel’s outreach, we’ve established lines of communication with the Next.js team. With this in place we hope to gain better insights into upcoming changes to the framework." So instead of having it in open, Netlify now have their own channel of communication with Vercel. This still continue to feel like a closed garden and makes it difficult for small vendors to have proper NextJS hosting. (Disclosure: I am running DollarDeploy which allows hosting NextJS (amongst others) on your own server. And we don't use docker!)
- xiwenc 1y ago
  Unfortunately commercial companies tend to work behind closed doors/gardens. We are working on Low-Ops.com and would love to fully support NextJS. Self-hosting is the future :)
- erozzy 1y ago
  (disclaimer: I work at Netlify) It's not a 1:1 channel, we're pushing for as much work in the open as possible, and extending the OpenNext group to more members. IMHO one major challenge is the amount of work one has to do to build an adapter, if we can make the spec leaner and move logic out of e.g. the CacheHandler, that's gonna make it easier for you to create your own (or you could state that some features/modes are not supported - but for that, you'd need to have a very good idea of what these even are)
  - huksley 1y ago
    Thank you for clarifying! There is a open source cache adapter but it does not support NextJS 15 at the moment.
    - serhalp 1y ago
      Ooh, interesting. We didn't know about this. Is this it? https://github.com/caching-tools/next-shared-cache/tree/canary/packages/cache-handler https://github.com/caching-tools/next-shared-cache/tree/cana...
      - huksley 1y ago
        yes, there is even the official example here https://github.com/vercel/next.js/tree/canary/examples/cache-handler-redis 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 https://github.com/huksley/next-cache-handler
- serhalp 1y ago
  This is a great point and definitely something we're mindful of. That sentence actually ended with "and share these with the community" in the draft, but we can't make promises on behalf of the Next.js team. Our hope is that the OpenNext initiative's growth and connections with the Next.js team is just a first step toward shifting some Next.js governance out to the open. The article calls out that the OpenNext members are hoping to contribute to public RFCs in the future, with Next.js core team collaboration.
tmpz22 1y ago
Hey bro would you like a SaaS Convenience layer for your SaaS convenience layer? No, no the issues and costs won't compound.
deleted 1y ago
[deleted]
new_user_final 1y ago
Reading this post feels like nightmare and why should Vercel work for others? They are kind enough to notify others about incoming changes. OpenNext, AWS Amplify, Cloudflare, Netlify can deploy next.js and the customers has no problem.
_fat_santa 1y ago
I think NextJS is still a decent framework to use, so long as you're not going into any of their RSC or other "full stack" features and use it with the "export" flag (which just generates HTML/CSS/JS that you can upload anywhere). One thing that is very annoying is that their next/image component still does not support "export" and only works if you deploy to Vercel. Considering that Gatsby figured this out so early on is just shameful. Granted there are a couple of 3rd party packages that add proper image support like Gatsby had, it's still very annoying and quite frankly sad because we all know this is a business decision to keep folks locked into Vercel.
vegancap 1y ago
Worked at Netlify briefly, and the amount of plates they have to spin to keep all these integrations so smooth was super impressive. Some super impressive stuff under the hood. Also a lot of coordination between different projects. Shame to see Vercel not assisting with these efforts as other frameworks do.
moribvndvs 1y ago
> 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 the core of this blog, camouflaged by concerns of openness. I’m most certainly agree with openness, and quite honestly I dislike NextJs and Vercel, but suggesting that side stepping lock in altogether by simplifying down to traditional techniques is not “serious” makes me bristle a little, especially when you say we can’t do something that we have been doing for many, many years without your platform.
- serhalp 1y ago
  The ability to self-host on serverless compute is just a subset of the challenges. Even with your own VPS or ECS setup, I think it's legitimate to say a serious project requires server redundancy, and as soon as you have more than one running server it opens up requirements to synchronize cache state, which is a significant challenge. This has nothing to do with serverless architecture.
- willriches 1y ago
  It's their whole business model, to convince developers that their walled garden is the only viable option. I've met a lot of newish developers that believe it too.
- chacham15 1y ago
  > 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 of other primitives like the article mentions. E.g. a shared cache with proper invalidation mechanisms. If you dont need scale, then you're right, you dont have to worry about this. I will also note that it is slightly odd to use a framework like next.js if you arent (or planning on) running at scale because most of its features (e.g. SSR) are entirely performance oriented. 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.
atonse 1y ago
What's shocking to me is that they deploy "hundreds of thousands" of self-hosted apps? I wonder what percentage of overall NextJS apps are on Vercel, and what percentage aren't.
pjmlp 1y ago
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.

89 points by serhalp 1y ago

deleted 1y ago

[deleted]

I wonder if this blog post was prompted by this: https://news.ycombinator.com/item?id=43481295 https://news.ycombinator.com/item?id=43481295

addandsubtract 1y ago
100%. The OP said he works for Netlify and this seems like a verbatim repost of theirs.

huksley 1y ago

"Fortunately, thanks to Vercel’s outreach, we’ve established lines of communication with the Next.js team. With this in place we hope to gain better insights into upcoming changes to the framework." So instead of having it in open, Netlify now have their own channel of communication with Vercel. This still continue to feel like a closed garden and makes it difficult for small vendors to have proper NextJS hosting. (Disclosure: I am running DollarDeploy which allows hosting NextJS (amongst others) on your own server. And we don't use docker!)

xiwenc 1y ago
Unfortunately commercial companies tend to work behind closed doors/gardens. We are working on Low-Ops.com and would love to fully support NextJS. Self-hosting is the future :)
erozzy 1y ago
(disclaimer: I work at Netlify) It's not a 1:1 channel, we're pushing for as much work in the open as possible, and extending the OpenNext group to more members. IMHO one major challenge is the amount of work one has to do to build an adapter, if we can make the spec leaner and move logic out of e.g. the CacheHandler, that's gonna make it easier for you to create your own (or you could state that some features/modes are not supported - but for that, you'd need to have a very good idea of what these even are)
- huksley 1y ago
  Thank you for clarifying! There is a open source cache adapter but it does not support NextJS 15 at the moment.
  - serhalp 1y ago
    Ooh, interesting. We didn't know about this. Is this it? https://github.com/caching-tools/next-shared-cache/tree/canary/packages/cache-handler https://github.com/caching-tools/next-shared-cache/tree/cana...
    - huksley 1y ago
      yes, there is even the official example here https://github.com/vercel/next.js/tree/canary/examples/cache-handler-redis 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 https://github.com/huksley/next-cache-handler
serhalp 1y ago
This is a great point and definitely something we're mindful of. That sentence actually ended with "and share these with the community" in the draft, but we can't make promises on behalf of the Next.js team. Our hope is that the OpenNext initiative's growth and connections with the Next.js team is just a first step toward shifting some Next.js governance out to the open. The article calls out that the OpenNext members are hoping to contribute to public RFCs in the future, with Next.js core team collaboration.

tmpz22 1y ago

Hey bro would you like a SaaS Convenience layer for your SaaS convenience layer? No, no the issues and costs won't compound.

deleted 1y ago

[deleted]

new_user_final 1y ago

Reading this post feels like nightmare and why should Vercel work for others? They are kind enough to notify others about incoming changes. OpenNext, AWS Amplify, Cloudflare, Netlify can deploy next.js and the customers has no problem.

_fat_santa 1y ago

I think NextJS is still a decent framework to use, so long as you're not going into any of their RSC or other "full stack" features and use it with the "export" flag (which just generates HTML/CSS/JS that you can upload anywhere). One thing that is very annoying is that their next/image component still does not support "export" and only works if you deploy to Vercel. Considering that Gatsby figured this out so early on is just shameful. Granted there are a couple of 3rd party packages that add proper image support like Gatsby had, it's still very annoying and quite frankly sad because we all know this is a business decision to keep folks locked into Vercel.

vegancap 1y ago

Worked at Netlify briefly, and the amount of plates they have to spin to keep all these integrations so smooth was super impressive. Some super impressive stuff under the hood. Also a lot of coordination between different projects. Shame to see Vercel not assisting with these efforts as other frameworks do.

moribvndvs 1y ago

> 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 the core of this blog, camouflaged by concerns of openness. I’m most certainly agree with openness, and quite honestly I dislike NextJs and Vercel, but suggesting that side stepping lock in altogether by simplifying down to traditional techniques is not “serious” makes me bristle a little, especially when you say we can’t do something that we have been doing for many, many years without your platform.

serhalp 1y ago
The ability to self-host on serverless compute is just a subset of the challenges. Even with your own VPS or ECS setup, I think it's legitimate to say a serious project requires server redundancy, and as soon as you have more than one running server it opens up requirements to synchronize cache state, which is a significant challenge. This has nothing to do with serverless architecture.
willriches 1y ago
It's their whole business model, to convince developers that their walled garden is the only viable option. I've met a lot of newish developers that believe it too.
chacham15 1y ago
> 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 of other primitives like the article mentions. E.g. a shared cache with proper invalidation mechanisms. If you dont need scale, then you're right, you dont have to worry about this. I will also note that it is slightly odd to use a framework like next.js if you arent (or planning on) running at scale because most of its features (e.g. SSR) are entirely performance oriented. 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.

atonse 1y ago

What's shocking to me is that they deploy "hundreds of thousands" of self-hosted apps? I wonder what percentage of overall NextJS apps are on Vercel, and what percentage aren't.

pjmlp 1y ago

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.