Open peter-jerry-ye opened 1 month ago
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.
@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?
@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.
@calvinrp Thank you very much for your kind explanation. I see that jco server
seems to be using Web Workers to solve this issue.
Happy to update on progress. It sounds like what I'm working on will be useful to you.
Hello,
Since the
wasi-http
defines a server that accepts an incoming request and returns a response, andjco
have the ability to serve a server, is it possible to provide a conversion between theWasiHttpIncomingHandler
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?