[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:

1. 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!")
     }
   }
   

2. 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)
     }
   }
   

3. 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.

[DenaliDeMots]

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.

[noga-aviator]

any update on this ?