remix
remix copied to clipboard
[Feature]: Cloudflare Workers ES Modules Support
What is the new or updated feature that you are suggesting?
Cloudflare Workers has recently GA'd support for ES modules and now uses this format as the default in templates.
ES modules brings three changes that affect Remix:
-
The entry point syntax is different
Where before, you set up a Worker using the service workers syntax, you now export a fetch handler:
// Previous service worker syntax addEventListener('fetch', (event) => { event.respondWith(async () => { return new Response("Hello, world!") }) }) // New ES modules syntax export default { async fetch(request, env, context) { return new Response("Hello, world!") } } -
Bindings are no longer global
Previously, any bindings of your Worker were available in the global scope. This pollution was part of problem with the service worker syntax, since there was no 'neat' way to pass them to a handler. Now, these bindings are available on the
env(environment) object.// Previous service worker syntax addEventListener('fetch', (event) => { event.respondWith(async () => { const value = await MY_KV_NAMESPACE.get("key") return new Response("Value retrieved from KV: " + value) }) }) // New ES modules syntax export default { async fetch(request, env, context) { const value = await env.MY_KV_NAMESPACE.get("key") return new Response("Value retrieved from KV: " + value) } } -
Finally, Durable Objects are available when using ES modules syntax
Durable Objects are powerful database primitives which I personally think are better suited to session storage than KV. KV is eventually consistent, so competing requests could easily squash values. Durable Objects, on the other hand, act as a point of synchronicity, as only one instance (for a given identifier) can ever be in existence. This controller can act as a gatekeeper, and removes the possibility for mistakes if you race data writes. Durable Objects are automatically created near to the user who requested them, and they can migrate as needed. They can also be restricted to a given jurisdiction, which is really useful (particularly for user data) in the context of GDPR etc.
Why should this feature be included?
- Durable Objects support would bring a great alternative to KV for
SessionStorage. - ES modules syntax is the default for Cloudflare Workers going forward. Adopting this would mean less friction for users who want to adapt their Worker, and also means documentation can be more easily understood between Cloudflare and Remix.
- Full-stack Cloudflare Pages uses ES modules syntax, which would offer Remix users another target to deploy to, which offers a variety of new functionality such as rollbacks, preview URLs and git provider integrations.
I have already written an adapter for ES modules, a Cloudflare Pages project, and Durable Objects-backed SessionStorage. We'd need to work out a couple of things to finalize how that gets integrated (e.g. how a developer could specify a jurisdiction for a Durable Object), but it's pretty much there.
Will it be possible to create API endpoints using the same worker? I'm looking at using WebSocket with Durable Objects. Or do I need to create and deploy a separate worker?
The Remix Approved™️ way to create API endpoints would be with Resource Routes.
However, with the current Cloudflare Workers integration, Remix leaves you with worker/index.js which actually registers the Remix logic in your service worker. Assuming that stays much the same, you'd be able to do a check for "if incoming request has route /api/my/endpoint, then do this, else, serve Remix stuff".
So the answer is yes. Just depends on how you prefer to separate the work.
Is it correct to say that resource route won't have access to any Cloudflare API (KV, DOs etc), even with the integration? And the only way is to use the worker/index.js file directly.
No. With the getLoadContext function, you can pass through KV & DO namespaces to your Remix loaders :)
Cool. Thanks for the pointer. And look like the same context is also available in action function too.
Thank you for the work here, @GregBrimble! We are anxious to make this change.
I have already written an adapter for ES modules, a Cloudflare Pages project, and Durable Objects-backed SessionStorage
Did you make a PR with this work somewhere?
Do we need to make any changes to our compiler? Currently we output CommonJS from our server build, but I believe we then webpack it so it runs on CF workers. Maybe that's the only piece that we need to change?
any update on this ?
I took at crack at this today. I think it may work now that Remix can generate ESM output.
I've been interested in using Durable Objects with Remix, so I took a stab at this. Using Cloudflare's Typescript/Rollup durable object template as a starting point, I adapted the Remix cloudflare-workers template to bundle for Cloudflare's new ES Modules syntax. My example includes passing a durable object into Remix through the loader context.
You can clone my template and start experimenting with Durable Objects. I hope others find this useful. I'd be happy to work on a PR to get this into create-remix if that's helpful to the community.
https://github.com/DenaliDeMots/remix-cloudflare-es-modules
Note: I wasn't able to fully replicate the asset handler function due to this issue with @cloudflare/kv-asset-handler. Until this gets fixed, you won't be able to take advantage of getAssetFromKV's cacheControl options.
I added an implementation that resolves this issue in #4676 by adding a new adapter (necessary due to the way @cloudflare/kv-asset-handler imports manifest info).
@huw hi friend, can you put your library on npm?
Nah, because I don’t want to be responsible for it. But it’s not difficult to clone a subfolder of a git repo or just patch the existing package directly with my code.
I just published a small adapter for Cloudflare ES Module Workers: https://github.com/xanderberkein/remix-cloudflare-module-workers/
This was done in #6650 by @pcattori