Webassembly support?

[Boscop]

Does reqwest work with wasm-unknown-unknown target, e.g. in a yew app to do ajax requests?

[sagebind]

Seems like an http client like this would be really heavy overkill to just do some ajax requests. Things like thread pools, TLS, connection pools, etc are not needed in the browser, since the browser handles all those for you.

[corbinu]

I am starting work on this. My thought is actually to simply have reqwest hand everything off to the fetch API. However that should be what projects depending on reqwest need if they have reqwest as a dependency (Which is my case).

[theduke]

Hey, I really support this.

It would be awesome to have the same code work on wasm and regular Rust.
That way you could reuse, eg, API clients on the frontend and backend.

As hyper wouldn't work in the browser anyway, my idea was also to use fetch under the hood and just provide the same API.

@corbinu did you get anywhere with your implementation?
Otherwise I might give it a go.

[corbinu]

@theduke It was a bit harder than I had hoped and I work in eCommerce so November was basically a goner for me as far as open source is concerned. I really do want to get back to this though so would be very happy if you wanted to collaborate.

[theduke]

@seanmonstar is this something that's at all reasonable for you or do you see this as definitely out of scope for reqwest?

[seanmonstar]

@theduke the idea sounds reasonable, but I don't know if in practice it's an incredible burden to support all of reqwest's features using browser APIs or not. I haven't look into it at all.

[theduke]

I've written a bit of wasm code now with web-sys and the futures integration.
It works quite well and I think most features should be supportable.
Figuring out the feature mess won't be easy though, I reckon.

I'll give it a try over the next few days and see how it feels.

[corbinu]

@seanmonstar If this is not something your interested in I understand. However I do think that reqwest would actually probably get a lot of traffic on npm if it were available as a WebAssembly module.

Also my use case is I am porting over a DB driver I have in TypeScript to Rust. This module currently uses Wreck as an HTTP library. I want to be able to use the same driver both for new Rust projects and my existing TypeScript apps. So the driver needs to be able to compile into WebAssembly. So I need an HTTP client that can compile also. I have a feeling this will be a very common use case.

For example front end libraries in Rust are already popping up. They would probably love to use reqwest rather than calling out to something like Axios.

@theduke When I had started I actually got thinking it might be better to create a new fork and strip out all the hyper parts but keep a reqwest compatible API. That way it could also only support the async API. Then look at merging the projects back together after I got it working and it could compile on stable. What are your thoughts?

[corbinu]

@seanmonstar I am wondering your thoughts also on a fork that would have the intention of merging back in once async/await futures are stable?

Also I think best first steps would be to migrate to Rust 2018 and Futures 0.3 Is it alright if I open PRs for those?

[seanmonstar]

Switching to the new edition would require the newest compiler, and I've generally tried as best as I can (sometimes dependencies use new features in patches) to not require new compiler in patch versions.

We also can't adopt Futures 0.3 yet since it requires a nightly compiler.

[corbinu]

Ok totally makes sense.

Sorry I should have been clear I was just thinking the async module with futures since that was nightly.

So that makes me more apt to take this route. How would you feel about a fork that is meant to run only on nightly for now that way it uses all the new stuff but it keeps the API so once all of the things are stable could be merged back in?

[David-OConnor]

This would be great! I'm working on a wasm-bindgen-based frontend framework, and am looking for a way to make http requests in the browser. Have been wrestling with the web_sys fetch API, trying to make a high-level API wrapping it... seems similar to reqwest's lane.

[corbinu]

@David-OConnor I have started work on a forked lib for this I am thinking of it as maybe a future vision for reqwest as I totally understand @seanmonstar 's desire for maintaining stability for current users. I will be publishing the repo in the next few days as work allows if you want to participate. I am also happy to add you @theduke. I already made it async only and migrated to Rust 2018. The plan for now is to base it on async/await and make it work in nightly rust + WASM in the browser as a replacement for axios + WASM in node as a replacement for Wreck

[David-OConnor]

I'm down. This would make sense as part of Reqwest, but another approach is a standalone, high-level crate that could be a go-to for making requests in the browser via wasm32-unknown-unknown. (Like you implied, an Axios analog for wasm-bindgen) Perhaps this makes sense, given Seanmonstar's concern, and the undefined timeline of when you could merge your branch into the main. What's driving it being nightly?

[seanmonstar]

If it's possible to support WASM already on stable Rust, and it's reasonable for reqwest's feature set, I'm all for getting into reqwest ASAP. Does WASM support require anything unstable, or could we leave async/await as a separate thing?

[David-OConnor]

WASM doesn't require anything unstable; the wasm32-unknown-unknown target now works on stable rust.

[theduke]

No it's all perfectly possible on stable. It just needs futures and wasm_bindgend_futures.
The browser event loop takes care of the rest, so there's also not much need for custom future based work.

I've also done a prototype and what I've noticed:
you basically can share almost no code.

I think the most sensible thing to do is to just add a new module with it's own ClientBuilder and Client which remain API comptatible as much as possible.
The feature dance is a bit challenging to get right in a clean fashion but doable.
And of course a lot of features aren't implementable (custom connectors, tls settings, timeout settings, proxies, ...).

Otherwise it's possible to get to a very similar API.
I guess we'll need to see if it's worthwhile to actually include it in reqwest.

[andykais]

Hey all, I just wanted to share some thoughts that may widen the scope of the issue. WebAssembly can target nodejs as well as the browser. If this library goes the route of supporting webassembly, it would be awesome if it were usable in nodejs as well.

I specifically like the idea of writing node libraries that can take advantage of rust when making http calls (scraper libraries come to mind right away)

[piranna]

Any update on this? I'm trying to port speedtest-rs to Wasmer and as stated at nelsonjchen/speedtest-rs#20 (comment), I've found that reqwest fails to compile to wasm32-wasi on net2-rs... Since Wasmer is a posix-like WebAssembly environment instead of a browser-like, is there any clue about how I can fix that?

[theduke]

WASI doesn't support asynchronous sockets, so it probably won't get support in mio. Which means the whole reqest/hyper/tokio/mio stack won't work there sadly.

I haven't found any http client compiling to WASI anywhere, sadly.

[piranna]

Being a new ABI, it's strange it doesn't support asynchronous sockets, in fact I would not have added synchronous ones due to performance... But it's true that (fake) asynchronous APIs can be build on top of synchronous ones, so maybe it can get added some time in the future.

[seanmonstar]

I'm not familiar with all the details of WASI, but if there's native support for xhr/fetch, then I imagine reqwest can conditionally use those instead of hyper.

[piranna]

Not xhr/fetch like since WASI API is more like syscalls, but it has support for Berkeley sockets.

The thing is that in fact net2-rs already have wasi support, so I don't know why it crash... :-/ It's easy to reproduce, just only exec cargo build --target=wasm32-wasi in reqwest source code and you'll get the error at compile time.

[JMLX42]

I'm not familiar with all the details of WASI, but if there's native support for xhr/fetch, then I imagine reqwest can conditionally use those instead of hyper

AFAIK fetch is provided by stdweb.

[theduke]

It's important to distinguish between targets.

If you want to run wasm in the browser, you can use wasm-bindgen/web-sys and use fetch or good old XMLHttpRequest.

WASI is a different target that is for non-browser environments. All you get there are some low level syscalls including synchronous sockets. (WASI might get async sockets in the future, but I don't think it's currently worked on).

[seanmonstar]

#630 sees a WIP start for adding wasm32 support. Various things don't work, and I don't typically do things with WASM, so if you want to comment or help out, the more the merrier :D

[seanmonstar]

I've merged #630 which supports wasm in the browser. I'll open new issues for things still missing.