enable access to cloudflare runtime

[AirBorne04]

Changes

• adding a runtime symbol onto the request object to enable access to the cloudflare runtime, therefore enables to KV, Durable Objects, R2 services

Testing

Take any example from the repo and add cloudflare to astro. Add the following lines into the index:

// get runtime
const runtime = Reflect.get(Astro.request, Symbol.for("runtime"));

if (runtime && runtime.name === "cloudflare") {
  console.log("Running on Cloudflare Workers");
}

Docs

This would add a piece of documentation to the cloudflare worker how it is possible to access services like KV, R2 and Durable Objects.
/cc @withastro/maintainers-docs for feedback!

[changeset-bot]

🦋 Changeset detected

Latest commit: a134e6e

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[AirBorne04]

This is a draft, because i would like some feedback, if there is a wish to integrate the option to getRuntime across other adapters as well, or if it is ok to just go with a cloudflare option right now. I am also not sure if there are similar cases on the other platforms.

[matthewp]

Hey @AirBorne04, I think that this feature makes sense staying in the cloudflare adapter for now. I'm not sure how generic of a need there really is for this. Outside of cloudflare env is just the environment variables as far as I'm aware.

From an implementation perspective this is probably a great solution. From an API perspective it might be a bit low-level for a lot of users who are unfamiliar with symbols. Think we could hide that implementation detail behind a function? Something like:

---
import getRuntime from '@astrojs/cloudflare/runtime';

const runtime = getRuntime(Astro.request);
---

which would just grab it from the symbol.

In the future if we ever have some sort of "context" idea like in this RFC: withastro/roadmap#230 then that might be a better place to put it. But I think that idea needs to bake for a while longer.

[AirBorne04]

Yes I will add the ˋgetRuntimeˋ as an API. For the different runtimes it is not only env variables (But probably the first to spot). In cloudflare it is Platform Features, in netlify it is (data through context and also runtime features through Deno)[https://docs.netlify.com/edge-functions/api/], I think it makes sense to define a general way how to get access to these runtimes / context. Gonna check out the rfc for context.

[awwong1]

I am very excited for this PR. Was just running into an issue binding the Cloudflare environment variables but being able to access them directly from the Env would be great.

[AirBorne04]

@matthewp from my point of view it is ready to go. 👍

[matthewp]

Thanks so much for this!

[emmanuelchucks]

How can I access this in dev/HMR mode? Currently I have to manually run astro build and then wrangler pages dev after each change.

[awwong1]

How can I access this in dev/HMR mode? Currently I have to manually run astro build and then wrangler pages dev after each change.

My current process is I run wrangler pages dev dist --live-reload, which will HMR reload on any changes in the dist folder.
You could also configure nodemon to run astro build anytime one of your source files change, or use something like

astro build && fswatch src | (while read; do npx astro build; done)

[emmanuelchucks]

Kinda slow but seems like the best solution for now. Thanks

[jimjimovich]

@AirBorne04 Thank you! This really opens up a lot of use cases for Astro on Cloudflare!

[AirBorne04]

thank you! @jimjimovich
If you like this one, also check out the latest addition to the adapter #5347 😄