Website migration to Vercel

[ovflowd]

Hey, I'm opening this issue to keep publicly tracking the conversation we have with a currently ongoing effort to evaluate a possible migration of the https://nodejs.org website toward Vercel infrastructure.

This consideration initially started because we're adopting Next.js (full SCG) with nodejs/nodejs.org#4991 and the fact that by adopting Vercel's infra, we would have a set of benefits.

It is essential to mention that if we decide not to use Vercel infra, we might still want to consider having our Next.js installation run with SSR (Server-Side Rendering) on our Infrastructure maintained by the @nodejs/build WG.

What is this proposal about, and why?

On why adopting Next.js SSR/ISR

• Incremental builds that allow us to quickly build on our production and staging infrastructure with seconds between each deployment
• Internationalisation features that increase our accessibility to an international audience. Such as automatic language detection and redirection (Accept-Language), hreflang, and other features.
• Built-in Middleware that is highly customizable and would allow us to offload some of the Rewriting Rules we use on NGINX that are harder to maintain (require special access to the server, more prone to error, require specialized knowledge on NGINX).
  • This would allow us to have better i18n routing/redirection, better 404 redirection/routing
  • This would allow us to ditch the /pages/{twoLetter} directory format of having one repeated page for each locale and adopt a similar design from https://github.com/nodejs/nodejs.dev, where we have a single file for a page and multiple files for content. (Example: here and here).
• Caching of Assets, Pages, and API requests.
• It would allow us to introduce some of the Microsites, such as the Google Calendar microsite, instead of using the default Google Calendar Share page
• It would allow us to introduce API requests to lazy-load/offload rendering of specific components that are performance hungry, like the Previous Releases page that loads a huge JSON on every request.
• Introduction of Search (with Elasticlunr or alternatives) with indexing, server-side processing, and caching. Which would allow us to search for content on the website. (Gatsby supports that on SCG, but with the caveats that the client does the processing "statically".
• And more features that Next.js support.

On why adopting Vercel infra

• Easier management of deployments and a more seamless experience for live previews, staging branches, rollback, metric management, load balancers, and better auditing of deployments
• Not a single point of failure, as it is not hosted on a single server
• No monetary costs
• Less requirement of dedicated knowledge of our current build system infrastructure and special access and unique understanding of our legacy systems

What is this proposal not about

• Only the rules/pages handled by the nodejs.org repository are what we're considering offloading to Vercel. This means only the NGINX rules that currently point to the statically generated files from the nodejs.org repository, as pointed out here
  • In practical terms, a proxy (rewrite rule) would be added in place to forward the requests to the Vercel-hosted App (as a reverse proxy, forwarding also headers, query parameters, et cetera)
• All dist, downloads, releases, dist.json, generated metadata, other subdirectories, and microsites will remain on our current Build Infrastructure with the same NGINX rules.

What was talked about so far

• We had initial discussions with Vercel's Staff
• Meetings were held off with the Website WG and some people from the TSC and Build WG together with some people of the TSC and together with the Foundation Staff (@joesepi, @richardlau, @Trott, and others)
• In-Slack communication has happened with several people from the Foundation, Vercel, and Node.js
• This issue was finally created to publicly "audit" that this whole proposal is happening
• I believe further talks with the Build WG, Release WG, and the TSC will be done, including more discussions with the Foundation.

Next Steps

To be documented

[Trott]

• Meetings were held off with the Website WG and some people from the TSC and Build WG together with some people of the TSC and together with the Foundation Staff (@joesepi, @richardlau, @Trott, and others)

The others were @rginn and @kyliewd.

[mcollina]

I'm absolutely in favor of adopting Vercel to improve the dx and have staging branches etc. However our website is mostly static information: it seems a waste of energy to render things all the time.

My understanding of this proposal is that we would deploy:

1. Cloudflare CDN on top
2. Nginx on our single server:
   a. to serve the release downloads.
   b. to proxy to Vercel.

This does not improve the reliability of our infrastructure because it's still passing through our single nginx server. It will instead increase the load on our single server and worsen the response latency for our end users. I'm not going to block this for that anyway.

I think that the proposed architecture is less reliable and not something we want to have. Happy to help designing something better with the tech at play (e.g. completely bypass our nginx and proxy vercel from cloudflare).

[ovflowd]

Thanks for the feedback, @mcollina! I also feel like using Cloudflare directly could be an interesting solution. Maybe, through their Workers feature or something (as it allows path matching)

Anyhow, just wanted to make it clear I just gave an example, of how we could achieve using Vercel just for the website without getting rid of the current infra for downloads/releases.

I do believe using SSR will come at handy for all the features we want to introduce. It also improves build, reduces memory usage during build time and allows us to do other things that right now we've done some not ideal approaches on the initial PR for Next.js.

[leerob]

Hey folks! Happy to answer questions about Vercel.

I'm absolutely in favor of adopting Vercel to improve the dx and have staging branches etc. However our website is mostly static information: it seems a waste of energy to render things all the time.

What do you mean by a waste of energy? Is this for Vercel? If things are static, those generated assets are deployed to our Edge Network (CDN). You wouldn't need to use another CDN on top.

I do believe using SSR will come at handy for all the features we want to introduce. It also improves build, reduces memory usage during build time and allows us to do other things that right now we've done some not ideal approaches on the initial PR for Next.js.

This is one of the nice things about Vercel – you can choose static or dynamic, on a per-page basis, without needing to change infrastructure. The Node.js site currently has a lot of pages (I think over 1,000?). Plus you have internationalization, so multiply 1000 times the number of languages. You'll likely want to defer the generation of some of the infrequently used pages outside of the build (to prevent really, really long builds).

As mentioned above, I've approved an open-source sponsorship to provide a free Vercel team for the Node.js site 😄

[mcollina]

What do you mean by a waste of energy? Is this for Vercel? If things are static, those generated assets are deployed to our Edge Network (CDN). You wouldn't need to use another CDN on top.

The content is mostly static, but this proposal is about making some of them dynamic to deal with a few rough edges of the current solution.

---

Why we need a CDN/NGINX on top

Most of the complexity we need to deal with comes from technical debt.

We are currently serving all Node.js binaries from the same infrastructure of our website.
We cannot easily change those URLs because a lot of other tools everybody uses depends on them. Latest stats put this traffic at around 4.5million daily downloads during weekdays. (Cloudflare+NGINX allows us to serve all of this from a single server).

As you would expect from a project of this size, very few people can push binaries. On the other hand, we want a contributor friendly website, and let people publish changes to our website from GitHub.

I would personally feel uncomfortable deploying the binary downloads as part of our website.

[ovflowd]

@mcollina I don't want to sound like I'm repeating myself (So I apologize if it sounds repetitive), but again, we don't want to (for now, it's not even part of the plans) change where the binaries and downloads and archives are. Just the live website 😅

(Note that we didn't mention at any moment that we should get rid of Cloudflare or NGINX)

[mcollina]

@ovflowd I was responding to @leerob that said:

You wouldn't need to use another CDN on top.

However, this is exactly what we are planning to do.

[ovflowd]

Gotcha, ty for clarifying, and sorry for the confusion 👀

[mhdawson]

@nodejs/build to make sure build team is aware.

[leerob]

Ah, apologies @mcollina I was misunderstanding how you wanted to serve those binaries. Agreed that putting Cloudflare in front of Vercel here would make sense!

[mhdawson]

Teasing apart the downloads from the website itself is a good goal, but as Matteo mentioned this part does not get us many of the benefits:

b. to proxy to Vercel.

I guess the challenge is that the download/sites are tightly coupled in terms of existing URLs and we can't use dns to have traffic directed to different places for the downloads/site content?

If that is impossible then possibly using CloudFlare as the proxy to Vercel/our existing server for downloads might be possible (that might possibly be what was suggested above). We mighte even be able to set it up so that we do both in parallel to test out where test.nodejs.org splits requests across the two locations while nodejs.org continues to serve both from the existing server?

[ovflowd]

I guess the challenge is that the download/sites are tightly coupled in terms of existing URLs and we can't use dns to have traffic directed to different places for the downloads/site content?

Not really, if we do it through NGINX it's pretty easy, but it doesn't reduce the load on our servers. It would be a temporary solution.

Afaik, Cloudflare supports path-based proxying tho. It is something that can be done through Cloudflare Workers, as I mentioned before...

We could also, of course, make a Cloudflare rule to redirect the downloads/binaries path to get.nodejs.org or something of sort.

[ovflowd]

@mhdawson quick-question: do we use a free Cloudflare license?

[targos]

We have a free Business plan

[ovflowd]

We have a free Business plan

Sponsored? Cool, I suppose then all usage pricing goes to 0, right? Because of https://developers.cloudflare.com/workers/platform/pricing/