-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support WebAssembly Component bindings, aka wasip2, in addition to javascript bindings #2294
Comments
Added example in #2290, and for additional clarity here's what's upcoming in terms of wasm32 targets in Rust. Eventually I think we can remove the feature flag and instead use the target as a differentiator of when to use the p1 bindings v.s. p2 bindings. |
@seanmonstar would you like to see any additional commentary/fixes/thoughts here? Do you have any questions? One question I have for you is if you think we could include this in the synchronous version of the crate, since wasip2 components don't technically native async we could avoid the use of the |
One of the major issues I experienced with While I would be happy to have a 100% shim with warnings when features are not available when using the |
@smndtrl I think your comment makes a lot of sense. With the current level of standard HTTP support for WASI, there's not really an expectation for a user to be able to use cookies/proxies/tls right now. We could always model that in terms of a different interface, but it would be up to the WebAssembly host to implement that and that doesn't belong in a general purpose library. The reality right now is that this type of feature would make Wasm applications in Rust that use HTTP look a lot nicer, and it would only be a small step for existing Rust applications that hope to seamlessly swap over to the wasi-p2 target. The shim with warnings (or failure to compile) is essentially what I was thinking for the first pass here. I'm going to spend a bit of effort making the PR smaller in scope to, hopefully, make the surface area smaller for testing + questions |
The current wasm implementation supports compiling to wasm with
wasm_bindgen
, which is meant to provide bindings for usage from JavaScript in the browser. This aligns with many of the concepts from wasi_preview_1 and uses the browser'sfetch()
API to actually make the request. This works great for the browser, now there's tons of applications that want to use a higher level API for making requests from Wasm and run them on the server. The next iteration of WASI, wasi_preview_2, is the perfect basis for this.WASI Preview 2 released earlier this year WebAssembly/WASI#577 with a common set of standard interfaces, including
wasi-http
which provides an interface both for incoming and outgoing HTTP requests. What I would love is forreqwest
to support binding towasi:http/outgoing-handler
which would let Rust devs compile reqwest directly to a Wasm component targeting p2. I am a maintainer of wasmCloud which uses wasi-http for it's requests and, as you can see in this sample, using a higher level library in Rust greatly simplifies the code.I opened #2290 to start implementing this but I think there's a couple of questions to answer:
wasi-http
#2290 look reasonable or should we approach the problem differently? Most of the logic happens in the client'sfetch
function, and you can see the translation from the reqwest::Request and the wasi::http::OutgoingRequest.wasi-http
#2290 with the refactor or prefer for components to be a new folder? WASI Http module #1956 contains a reference implementation with slightly old bindings with a different file structureThis PR is essentially a duplicate of #1956, I just promised to open another issue so we can dedup as necessary.
I think this PR is related to #1977 but it might not entirely supercede it since there's a deeper discussion on abstraction.
Thanks @seanmonstar for being receptive to the issue + change. Looking forward to the discussion!
The text was updated successfully, but these errors were encountered: