Conversion between incomingHandler and request/response

[peter-jerry-ye]

Hello,

Since the wasi-http defines a server that accepts an incoming request and returns a response, and jco have the ability to serve a server, is it possible to provide a conversion between the WasiHttpIncomingHandler and a classic JS handlerfetch(request: Request): Promise<Response> (used by e.g. Cloudflare Worker and Deno)? Or should I develop a completely new shim based on the preview2-shim?

[calvinrp]

Hi, I've been working on exactly that. But requires JSPI or Asyncify to handle the asynchronous aspect. Let me know if you are interested in collaborating.

[peter-jerry-ye]

@calvinrp Hi, I wonder if it's possible to have a synchronous version MVP? I think the asynchronous might be better supported with WASI Preview 3?

[calvinrp]

@peter-jerry-ye I do have sync implementation working just for the incoming response handler, but limited to that.

If you want to do outbound requests or many things that rely upon wasi:io/poll or wasi:io/streams, then you will need async support.

The issue is the JS APIs that you need to use are async but the Wasm functions are sync (in WASI P2). There a few different ways to go about this. JSPI (JavaScript Promise Integration), which is a stack switching proposal, is the ideal implementation. It is behind a feature flag in V8 and expected to be released before the end of year. Asyncify requires a rewrite of the Wasm binary but could be used as a stop gap. Using Atomics and Web Workers is also helpful in some circumstances. Also, to a limited degree there is a path with synchronous XHR, Web Workers and Service Workers.

[peter-jerry-ye]

@calvinrp Thank you very much for your kind explanation. I see that jco server seems to be using Web Workers to solve this issue.

[calvinrp]

Happy to update on progress. It sounds like what I'm working on will be useful to you.