Open dario-piotrowicz opened 1 month ago
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
cc @jkhaui
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 addinggetPlatform
. (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 👍
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.
@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
I wonder if we keep using
getEnv
for this purpose, instead of addinggetPlatform
.
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. 🤔
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.
we already have "context" which changes for each request, so I need a different name for things that are consistent between requests.
Hello :wave:
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 :slightly_smiling_face:
Additionally I think @rmarscher already started experimenting with this in PR #795 + gist. But from what I can tell:
executionContext
and simply making it available throughgetEnv
(source), is that really the cleanest/best API? (for one, if would override any pre-existing env variable calledexecutionContext
)executionContext
only in dev mode)(@rmarscher please do correct me if I got any of the above wrong :pray:)
So I would imagine that some extra work/thoughts needs to be put into it :thinking:
Personally I think a new
getPlatform
utility (equivalent to the existinggetEnv
) 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 `loader`s API ([docs](https://remix.run/docs/en/main/guides/vite#bindings)) - `@cloudflare/next-on-pages`, Cloudflare's official adapter for Next.js applications also provides an API for this ([docs](https://github.com/cloudflare/next-on-pages/tree/main/packages/next-on-pages#cloudflare-platform-integration)) (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](https://qwik.dev/docs/deployments/cloudflare-pages/#context), [svelte-kit](https://kit.svelte.dev/docs/adapter-cloudflare#runtime-apis), [astro](https://docs.astro.build/en/guides/integrations-guide/cloudflare/#cloudflare-runtime) and [nuxt/nitro](https://nitro.unjs.io/deploy/providers/cloudflare#direct-access-to-cloudflare-bindings).