Migrating adapters out of the core repository

[matthewp]

Body

Summary

Find new maintainers for a few of the adapters and have core focus more on Astro core. Core will keep the Node adapter, because it is the most widely used, and the Vercel adapter, since they are the project's official host sponsor.

Background & Motivation

As Astro has grown the popular of SSR has increased, but we have been unable to keep up on issues with adapters. Additionally there are specific features that each adapter/host has that the core team doesn't necessarily have the knowledge to take advantage of.

The community has done a great job taking on the maintenance of many of these things and we want to officially hand over ownership. Additionally some 3rd party adapters such as SST adapter are among the best we have.

Goals

• Find new maintainers for the Netlify, Deno, and Cloudflare adapters.
  • If the respective companies are interested in transferring ownership, allow them to do so.
  • If not, reach out to current community maintainers who might want to take on support.
• Reduce the number of host-specific issues in the core repository, giving us more time to work on the core framework.

Non-goals

• This doesn't need to happen immediately.
• The goal is not to stop supporting the hosts; they will all continue to work unchanged. Additionally the adapter APIs will be expanded in the future to give hosts more ability to build host-specific features on top.

[jlarmstrongiv]

@matthewp the main problem I found when using edge adapters is the fact that the edge runtime is not the same as the node runtime.

However, there’s two contexts: building astro and running astro. It’s perfectly fine to use node apis and node c++ addons in the prior, not the latter.

One of the great benefits of why I chose astro was that I could deploy it anywhere. Perhaps, the authoring integrations docs could describe the edge runtime limitations.

Even better, it would be great if astro could detect if an integration (or even user code!) is using node apis and c++ addons in the astro middleware/astro component head to warn them of their impending incompatibility if they set their adapter to one of the edge deployment adapters.

Detecting the usage of node apis and c++ addons that don’t exist would tell users immediately if their code is incompatible and save integration maintainers’ time. For example, for my internationalization integration, I had to disable three other edge-incompatible integrations to debug the underlying issue in my integration.

[maddsua]

I've took a brief look at Astro codebase, and I have a concern about the possibility of core migrating into NodeJS ecosystem so far, it would become incompatible with Deno runtime. I'm not implying that it's gonna happen, but in case it does, I don't want to abandon an adapter after a breaking update comes out.

You may actually remember my willing to work on Netlify Edge adapter, it is still there, but to me it looks like only the core team knows where Astro is going to go in the future. I'm sure that somewhere on these pages is a lot of useful insights, sorry, didn't find what I was hoping to see.

Can we be sure that the core won't require Node-specific packages or system modules in the future?
I've just forked Netlify adapter, I'm basically ready to start working on it, but obviously I can't influence the core if it, let's say, starts aggressively requiring image service being enabled and sharp installed even if they aren't used at all.

I think a have a few good ideas about what to add to the Netlify adapter, but first some help with getting into maintainers "position" would be appreciated

Btw, using Astro for around 6 month, absolutely love it's SSG capabilities and developer experience. Clients absolutely love the speeed too

[Princesseuh]

Just for context, we have telemetry on adapter usage (which definitely helped in making those choices) and even combining Vercel and Netlify Edge adapters, it represents less than 0.7% of Astro users, with Netlify Edge in particular sometimes having only a handful of users per month.

[jlarmstrongiv]

@Princesseuh would you share that context to help us understand the Astro team’s decision? A pie chart like the one above or a screenshot of an existing visualization would be nice.

[Princesseuh]

I cannot share super precise stats, but the gist of it is that there's only really 4 adapters with a meaningful user count. In order of usage:

• Node
• Vercel Serverless
• Netlify Serverless
• Cloudflare

The rest of it is really mostly noise, with all the remaining adapters being in total less than 1% of Astro users. Among these, Cloudflare is the only one running on a separate environnement, and requires the most maintenance. I'll also note that SSR is in general a minority, even the Node adapter is a very small minority of Astro users. It's not perfect, but seeing the npm downloads for the various packages might help understanding the situation: https://npmcharts.com/compare/astro,@astrojs/node,@astrojs/vercel,@astrojs/cloudflare,@astrojs/netlify,@astrojs/deno

[maddsua]

Well, I'm not gonna say that the "Edge people" are super shy and they turned off any form of telemetry in their projects. I was using a list of Astro websites from https://astro.build/showcase/, and that's the data I've got from it. By the way, my graph cannot indicate whether they use a static CDN or a some form of SSR. Most of deployment platforms set 'server' header to the platform's name regardless of the actual software working underneath.
As I've said, let's see it Netlify is interested in maintaining the adapter, and if not, oh well, going SSG all the way I guess, cause this talk makes me question if anyone besides my team actually uses that.

[alexanderniebuhr]

Having contributed to the Cloudflare adapter and with my intention to continue doing so—aiming for a maintainer's status—I'm enthusiastic about the idea. I'm eager to see adapters transition out of the core repository and into community maintenance.

A person on Reddit suggested that Cloudflare and Netlify Edge can be handled by the same adapter

I respectfully disagree, especially if we want both runtimes to have comprehensive feature sets

[alexanderniebuhr]

Could it make sense to also open dedicated Discord channels for dev discussions, which only relate the specific adapter?

[yonnic]

i dont understand why vercel or astro dropped the vercel/edge part of the adapter and only support the middleware edge,
its a huge braking change. Middleware is not a replacement for the full edge functions. Now i have to rely on a fork with 7 stars from some random dude to stay on edge functions.... thinking of migrating away to cloudflare

[matthewp]

Because people regularly posted bugs because dependencies don't work in the Edge environment, creating a big maintenance burden. Even Vercel stepped back from suggesting use Edge functions for rendering, due to the fact that your database is (usually), not at the edge.

But if anyone really wants this functionality you can find the old code and create your own adapter for it. It's not all that complicated.

[maddsua]

i dont understand why vercel or astro dropped the vercel/edge part of the adapter and only support the middleware edge, its a huge braking change. Middleware is not a replacement for the full edge functions. Now i have to rely on a fork with 7 stars from some random dude to stay on edge functions.... thinking of migrating away to cloudflare

Same with Netlify lol. Welp, now we don't use Astro for SSR 🤷‍♂️