WASM Support

[janus-reith]

So far I was unable to load wasm from a local file, is this possible at the moment?

Workers recently started supporting a not-yet standardized way of importing wasm like an es module, which seems way more flexible than the previous bindings.
So one can just do it like this: import module from "./file.wasm"

Deno used to support a similar approach but removed it eventually with the longer term intent to reintroduce it when some outstanding questions are sorted out. Instead, Deno.readFile has to be used (or local file fetch) - However, the global Deno namespace seems to not be available from within the worker code.

I wonder how this could be worked around in an interoperable way that fits both CF Workers and Deno.

A. Use the import syntax and somehow make Deno.emit ignore that import, since pratically no further processing is required. Longer term the ES import would IMHO be the preferable syntax, however I don’t know if it is technically feasible, also another issue would be that at this point, the result would not be valid Deno code anymore, since that one would not know how to process this import outside denoflare.

B. Use the default Deno.readFile approach and thereby keep things the current Deno way. A very dirty workaround could be to as soon as such a readFile of a file with .wasm extension comes up, convert that line to an import. That way the result could run both on Deno and CF. However, partially stubbing Deno seems messy, likewise converting these reads of .wasm files to imports seems messy if not potentially dangerous too, since I might want to read some file with wasm extension for whatever other reason than to actually run its code.

Both options don’t really seem good at the moment, I wonder if there’s any better possibly that I missed?
An unrelated option is to embed wasm into js a base64, however I would assume that might have some performance implications, also I prefer to not have added build steps.

[johnspurlock-skymethod]

No WASM support yet, but let's think about it how it could be done.

You've laid out the current landscape well: there seems to be two ways to use WASM in a Cloudflare Worker today

1. Global variable binding: How to use WebAssembly with Cloudflare Workers
2. ES6 import: JavaScript modules are now supported on Cloudflare Workers

This is wrong, see below
What's interesting (based on the examples anyway) is that in style 1, the global variable binding seems to be typed as WebAssembly.Module, which is then instantiated with new WebAssembly.Instance(module). In style 2, the imported symbol is of type ArrayBuffer, instantiated with WebAssembly.instantiate(module), even though the blog says:

you can import WebAssembly as a module

So in style 2, it would appear there is no support for WASM module imports per se, just text and binary modules, as outlined further down in the blog. It's not implementing the esm integration proposal ahead of time (which is what I would guess Deno would do if they brought back support), just allowing for text and binary imports at build time.

Style 1 (global variable binding) should be fairly straightforward to implement in Denoflare. Injected global would be a WebAssembly.Module created either from a local file bytes (when "localIsolation": "none") or from a stream (when "localIsolation": "isolate")

Style 2 (module import) is trickier, since this syntax is not valid Deno. Maybe some tricks with import maps or providing override sources to Deno.emit would work, but Deno.emit is only used in "localIsolation": "isolate" mode (the default mode). I'm not sure how we could support style 2 in "localIsolation": "none" mode, since the root module is import()ed directly, an no way to provide overrides to an import() as far as I know.

Do you have existing code you're trying to get working with Denoflare? If so, I could prioritize getting that style working. Otherwise, I think the implementation approach might be:

1. Get style 1 working via denoflare push. i.e. implement the binding type during upload, ensure it works on Cloudflare
2. Get style 1 working via denoflare serve. i.e. inject globals/bindings of type WebAssembly.Module in both isolation modes
3. Think more about what to support in style 2 🤔🤔🤔. I think Denoflare's current approach of module-style code working as-is in both Deno and CF is great now, would be hesitant to start requiring rewriting steps during the build. Maybe style 2 would only be supported in "localIsolation": "isolate" mode and we document that, but then what about reusing code that tries to import text or binary modules in other Deno projects?

[janus-reith]

Thanks for the quick and detailed response!

In style 2, the imported symbol is of type ArrayBuffer, instantiated with WebAssembly.instantiate(module)

Interesting, I actually was not aware that their implementation differs from the ESM proposal.

Do you have existing code you're trying to get working with Denoflare? If so, I could prioritize getting that style working.

Thanks for that offer, no there‘s no urgent usecase actually, I‘m just creating some architecture concepts and am interested in general CF Worker/Deno interopability in that regard.

Style 1 (global variable binding) should be fairly straightforward to implement in Denoflare

I agree, this seems to be more straigtforward to implement and would not require manual build steps. I‘m not sure however wether that global binding approach is superseded by the module imports or if both should coexist.
Either way the module import would be favorable since it is more flexible and all in code, but it probably makes sense to add the global binding for now to have something.

I wonder if another approach might be feasible, which, just like my original option B., would involve an additional rewrite of imports at build time, but works with valid syntax: Using a local fetch which Deno supports, and for CF Workers rewrite this to one of these ArrayBuffer imports(This might not even be limited to wasm files in CF, idk.). That approach might be less error-prone than the opposite of interpreting the wasm import for Deno and could also be done after the Deno.emit step ran, until then it would still be valid Deno code. One caveat might be that while Deno would allow usage of WebAssembly.instantiateStreaming, the CF Worker probably needs to use WebAssembly.instantiate.
Depending on requirements and other CF Workers supported filetypes that can be imported, this fetch polyfill could be a simple implementation which really just replaces that one fetch line with an import line, or for other file types, gets the file content as string and exports it as separate file or inlines it.

[johnspurlock-skymethod]

Ok, more information on this after doing some investigation yesterday.

I was wrong in my earlier comment that the imported symbol is of type ArrayBuffer, I found it to be WebAssembly.Module at runtime on Cloudflare, just as the blog example showed. It's using the secondary overload of WebAssembly.instantiate, which returns a different type that the primary one! They do treat wasm modules somewhat differently than text/binary imports (which they also do support as you point out), the wasm blob's content-type is set to application/wasm on upload. It still differs from the esm integration proposal however, which will resolve to the exports of the module, not an object of type WebAssembly.Module as on Cloudflare.

Added wasm bindings to global variables locally to Denoflare to get denoflare push working, and found out they are only supported for the older script-based workers, not module-based workers, you get 10021 Wasm and blob bindings are not supported with modules; use imports instead on upload.

So, we need to figure out an approach to these non-standard imports sooner rather than later. Personally I don't use the older script-style workers at all these days.

My initial approach yesterday was to try to use import maps, which you can pass to Deno.emit, deno command line, vscode extension etc. What's intriguing about this approach is that it makes import module from "./lib/hello.wasm" (the example from the Cloudflare blog post), completely valid Deno code as is, provided a mapping is given at compile time to another module that default exports a WebAssembly.Module.

I got this working in denoflare push by including wasm sidecar ts files (e.g. hello.wasm.ts alongside hello.wasm), which includes code (specifically the wasm file path) that can be identified in the output of Deno.emit to rewrite to import statements immediately prior to uploading the worker. This works, but it would be nice if these boilerplate sidecar files were not needed.

And this only solves the problem for push. For serve, the import map would need to point each wasm import to another sidecar file that did something like new WebAssembly.Module(Deno.readFileSync(<full-path-to-wasm>)). And this would only work for serve in "localIsolation": "none" mode, for the default mode, we'd need another sidecar file that streamed in the module over rpc, since webworker container in default mode has absolutely no permissions, and does not even have the Deno namespace.

Ideally we could avoid the need these sidecar files to appear for users, since the import map could be pointed to either locally generated stubs on disk or perhaps a dynamic http endpoint at build time.

In general, I like the idea of using import maps, and looking into it more.

Another approach would be as you mention to not use import statements at all, just a function call that would work in Deno with no import maps, since we are already in the business of rewriting the Deno.emit output prior to upload on push.

fetch is an interesting idea, we already replace fetch with our own implementation inside the permissionless webworker. We'd just need a non-hacky way of identifying this code in the output, and hopefully replacing with import statements would still be valid? Have to try this out since fetch is async and imports, at least semantically, are not.

Another issue with this approach is Deno does not support local fetch relative to the current file. i.e. fetch('./hello.wasm') is not supported, only fetch('file:///abs/path/to/hello.wasm') with absolute file urls. And even if it did, it would probably be relative to cwd, not import.meta.url, which is how import statements are resolved. Think about the equiv of import mod from './child.wasm' in a subfolder of the project for example. So we'd have to force the user to resolve at every call site, e.g. fetch(resolve(import.meta.url, './hello.wasm')). Maybe we could provide a standard function from the project repo that would make this as simple of a one-liner as possible?

Anyway I'm gonna try investigating both approaches and come up with support in Denoflare, since now that it seems Cloudflare might up the script size limit, more interesting wasm scenarios become possible.

[johnspurlock-skymethod]

Ok, just pushed initial wasm support for module-based workers for denoflare push and denoflare serve in "localIsolation": "none" mode.

This is using the magic function approach kind of along the lines of what you suggested. Ended up being really clean, no extra module graph evaluations or special compiler options or temporary stub files. Just works as a standard Deno function when reusing code outside of Denoflare, since it builds on Deno's local file fetch and WebAssembly support.

See the hello-wasm-worker example for how the syntax looks from a usage point of view, and the docs for importWasm for how it behaves.

Can finally start doing wasm scenarios using Deno! So excited. Thanks for prompting me on this.

[janus-reith]

Wow that’s amazing @johnspurlock-skymethod!
Can’t wait to try this out, so many exciting possibilities with this!

[johnspurlock-skymethod]

Alright, shipped in Release 0.4.0

New doc page up: https://denoflare.dev/reference/wasm

[janus-reith]

Awesome! Do you accept donations? I would like to contribute € 100, that likely won’t make up for your time spent on this, but maybe could finance your coffee for a couple of days (or whatever beverage of choice)

[johnspurlock-skymethod]

That's generous of you, thanks! I just added a donation link to the homepage