Closed theduke closed 3 years ago
Thanks a lot for opening this issue! The main reason we don't really want to delve into building support for listeners and servers is the lack of multi-threading in WebAssembly (or to be more exact, the current lack of a spec for multi-threading and implementations outside the browser, since Emscripten does handle thread creation in the browser through web workers).
We could definitely do something similar to what you are describing, but we would immediately hit the single-threaded nature of Wasm modules, so real-world functionality would be rather limited (I did briefly discuss this in a past article as well).
So instead, we are building WAGI, which does exactly that - start a web server outside the Wasm runtime, but instantiate a new module for each request instead, leveraging the underlying runtime's multi-threadedness. Request bodies are read through standard input, and response bodies through standard output - hence the "GI" part of the name, coming from CGI. We're trying to make this as un-opinionated as possible, and we recently added support for this library, meaning guest modules can now make outbound HTTP requests.
For now, until multi-threading and networking are real things in WASI spec, WAGI seems to fill this spot quite well. Here is a draft article that describes the current state of development for WAGI, which briefly details the HTTP support, as well as a few other features.
(other platforms that tackle the issue of passing request data to WebAssembly modules are wasmCloud and Suborbital Atmo, you might want to take a look at their application models as well).
I hope this starts to answer your question - feel free to free to continue the discussion here, or over in the WAGI repo is you have specific questions about it.
Thanks, that clears it up.
WAGI is definitely a sensible approach, especially since it doesn't need any special API surface. Although interface types and a specialized interface would probably be preferable in the long term.
Anyway, thanks for the comprehensive response!
Thanks for working on this, very useful for experimental WASM work without having to write the wrappers and host functionality manually.
Are you planning on also implementing http server functionality?
Minimal http server functionality would be similarly useful as a POC for wasm server workloads.
I would imagine a simple implementation based on hyper, where the wasm side SDK takes a handler function that receives a
Request
and returns aResponse
. No streaming capability, only fully resolved bodies, like the client.Edit: ah, I noticed the
this library does not aim to add support for running HTTP servers in WebAssembly.
in the README. Is there a particular reason for that?