Feature Request: An API for accessing platform specific data/information/APIs (e.g. the Cloudflare ones)

[dario-piotrowicz]

Hello 👋

I'm opening this issue to ask if there is any intention or plan to support platform specific APIs (and I am specifically thinking of the Cloudflare APIs).

I think it might be worth clarifying the above: There is a Cloudflare deployment option to allow Waku applications to be deployed to Cloudflare Pages, this is already very nice, but one of the main reasons/incentives for developers to deploy to Cloudflare Workers/Pages is so that their application can make use of the various resources that the Cloudflare network provides (mainly bindings and waitUntil). So ideally Waku should provide an API to access such platform specific APIs (I would also imagine that other hosting platforms would have similar APIs but I haven't really looked into that to be honest).

I could not see this mentioned in the roadmap so I figured I could ask 🙂

Additionally I think @rmarscher already started experimenting with this in PR #795 + gist. But from what I can tell:

• his dev plugin hasn't been included in his PR, is this something that should not built-in into Waku itself?
• it seems like he's taking the executionContext and simply making it available through getEnv (source), is that really the cleanest/best API? (for one, if would override any pre-existing env variable called executionContext)
• either way, he didn't provide a production build solution (e.g. he's exposing executionContext only in dev mode)

(@rmarscher please do correct me if I got any of the above wrong 🙏)

So I would imagine that some extra work/thoughts needs to be put into it 🤔

Personally I think a new getPlatform utility (equivalent to the existing getEnv) would make sense, it could expose the platform specific APIs plus any other useful data/information regarding the current platform.

---

Other meta-framework examples

Most meta-frameworks do provide such APIs.

As React meta-frameworks go:

• Remix natively supports this, providing a context object in their loaders API (docs)

• @cloudflare/next-on-pages, Cloudflare's official adapter for Next.js applications also provides an API for this (docs) (Next.js by itself doesn't have such API, since it doesn't really have a built-in Cloudflare deployment solution)

as for non-react meta-frameworks, most of them do provide such APIs built-in, for example qwik, svelte-kit, astro and nuxt/nitro.

[dai-shi]

Thanks for asking.

There's no explicit plan, but I know there's a need.
I wonder if we keep using getEnv for this purpose, instead of adding getPlatform. (getEnv had to return serializable values, but it's no longer the case after #762.)
FYI, we plan to make it extensible with vite plugins. #806

[dai-shi]

cc @jkhaui

[dario-piotrowicz]

Thanks for asking.

There's no explicit plan, but I know there's a need. I wonder if we keep using getEnv for this purpose, instead of adding getPlatform. (getEnv had to return serializable values, but it's no longer the case after #762.) FYI, we plan to make it extensible with vite plugins. #806

I see, I'm glad you know that there's a need and are willing to enable it 🫶

Yes reusing getEnv (similarly to @rmarscher's POC) would work, potentially I would prefer getPlatform for a more clear API, but I understand that maybe not introducing an extra API can help keep the Waku API more concise/lighter 👍

[rmarscher]

either way, he didn't provide a production build solution (e.g. he's exposing executionContext only in dev mode)

Hi! Cloudflare injects those bindings into the environment automatically on their servers so my solution is only needed for the dev server.

I wasn't sure how to handle the wrangler peer dependency which is why I just posted an example instead of a package for now.

[jkhaui]

@dario-piotrowicz as was mentioned, feel free to include your suggestions for an adapter system in #806

Would be great to hear more about how other frameworks like Remix implement their adapter systems

[dai-shi]

I wonder if we keep using getEnv for this purpose, instead of adding getPlatform.

On second thought, getEnv should be kept for string. So, I would add a new API. As it would be used for #815 and others, getPlatform might not be the right name. 🤔

[rmarscher]

Since Cloudflare injects the bindings into the environment variables, the runtime adapter would need to move them from env to the new API location. Cloudflare also has a context object with a waitUntil method that can be useful. https://developers.cloudflare.com/workers/runtime-apis/context/

Hono adds the Cloudflare context to Hono's context as the "executionContext" - https://hono.dev/docs/api/context#executionctx

I like the idea of a context API for server components that adapters can populate.

[dai-shi]

we already have "context" which changes for each request, so I need a different name for things that are consistent between requests.