Alex Casalboni (Aug 11 2025 at 11:04): Alex Casalboni (Aug 11 2025 at 11:04):Hi all :wave: when working with the Component Model (wasip2), how can I use existing Rust libraries and SDKs that perform outgoing http calls?
Context: usually these libraries/SDKs rely on built-in/standard http interfaces rather than the WASI one (like reqwest in Rust). So you'd need to rewrite/patch existing libraries to use them in your component. I'm hopeful that the Wasm/WASI community has a plan to address this across all the supported languages. It feels unthinkable that each SDK/library needs to be patched or that you can’t reuse any existing library inside a component :thinking: or am I missing something important?
Also, I'm quite sure this is not limited to http. But not being able to use existing code sounds like a pretty critical blocker when it comes to reusing existing code/libraries.
It looks like this effort is currently blocked on the reqwest repo: https://github.com/seanmonstar/reqwest/issues/2294
Do you already know if it will unblock with wasip3?
Pat Hickey (Aug 11 2025 at 16:25):two answers to this. if you just want to write new code that uses wasi-http, use https://docs.rs/wstd/latest/wstd/
Pat Hickey (Aug 11 2025 at 16:27):if you want to use existing code that uses reqwest etc, thats still not possible and is blocked on not having enough labor available to collaborate with contribute to all of the projects upstream. the issue 2294 you see there was a really early prototype that one person put together but needed a lot of work with many different upstream projects in order to land, and ultimately there wasnt the resources to follow through on that, and still isnt.
Pat Hickey (Aug 11 2025 at 16:27):all of the major http frameworks for rust are built on the assumption that the operating system is providing a tcp (or udp fir h3) socket, and the rest of the http implementation is built in the library, including using linking in (or using OS interfaces that provide it) a TLS impl. wasi-http is designed for a very different use case, which is that the "operating system" is providing a pretty complete http implementation, takes care of TLS etc.
Pat Hickey (Aug 11 2025 at 16:31):so since thats a very architecturally different approach, its going to take time and energy to get it integrated with upstream, and in some cases its going to get pushback because it might break abstractions that upstream considered universal
Pat Hickey (Aug 11 2025 at 16:33):wasip3 doesnt do anything to change that situation, it makes many improvements to how the guests and hosts of wasi-http can work but not to the fundamental problem where this is a different sort of interface than any other operating system provides, so therefore its a pretty disruptive change to the existing libraries that build on windows-and-unix-like operating systems
Alex Casalboni (Aug 12 2025 at 10:14):Thank you @Pat Hickey :pray: super useful!
This sounds like a very intentional architectural decision indeed. My understanding is that such a decision makes 99% of existing code/libraries/sdks (that need to make http calls) incompatible with the WebAssembly Component Model.
In other words, I can't see developers (or API vendors) maintaining WASI-specific libraries and SDKs to interact with their APIs since they already maintain multiple SDKs for each major programming language. The end result is that building Wasm Components with http access requires reimplementing the http clients from scratch. That's not what developers love doing, in my experience.
I don't want to be disrespectful, but this sounds like a very critical blocker for the Component Model adoption. And it's quite different from other OS-level functionalities such as the file system. Imagine if all libraries that interact with the file system had to be re-written or patched to work properly with WASI. That would be quite unthinkable. So I struggle to understand why this is considered acceptable for the http interface.
Pat Hickey (Aug 12 2025 at 15:54):You're not wrong, these noncompatible things are a barrier to adoption. Like I said above, we do understand we need to work on them, and we will, its for lack of resources that we havent, not that we dont understand the importance of compatibility with the ecosystem.
Pat Hickey (Aug 12 2025 at 16:09):The way I see wasi-http is not as an interface that all existing software just fits into and you cross-compile to wasm and done. Its instead an interface that allows us to run untrusted software in new places where it was difficult or impossible before. We created wasi-http based on experience at Fastly creating their Compute product, and incorporating a bunch of design suggestions from envoy's proxy-wasm project, and right now I'm employed to work on wasi-http implementations at F5 for both nginx and the BigIP load balancers. In all of those scenarios, we had an engineering problem where we needed sandboxed compute, with the lowest possible overhead and fastest possible startup times, in an HTTP server/proxy setting, where the platform already provides the full http implementation and it would be a severe disadvantage for each wasm program to bring its own http stack and use raw sockets at the sandbox boundary. in all of these scenarios, wasm isnt trying to compete with traditional ways of deploying network servers that talk sockets using containers, using k8s or whatever other cloud technologies.
Prior to wasi-http the solutions to running code in these http server/proxy scanarios were much less developer friendly and/or less powerful - fastly had their own dialect of VCL, envoy had its own ecosystem of configuration and filters, nginx has its own config language and a pretty challenging environment to write modules in C, or you can use njs and lose a lot of js library compatibility, or you can use lua with lots of performance and language ecosystem drawbacks, and F5's BigIP has its own irules language which is a dialect of TCL - in short, none of these places could accept your 99% of existing code anyway, nor could they support code written for another one of these platforms. the value of wasi-http and components is that we make a compatible interface for all of that sort of proxy/server platform, and allow users to pick what suits them from a much bigger range of general purpose programming languages.
Pat Hickey (Aug 12 2025 at 16:15):so, if you're looking to components to provide a better way to deploy the stuff you currently use containers and k8s to do, its really not there yet. The whole container ecosystem has on the order of 1000-10,000x more engineering investment in it than wasi, so its not surprising to me that we dont measure up to all the nice things youd expect coming from that world. But there are a wide range of problems that containers arent the sweet spot for solving, the http server situations i cited, or plugin engines for your editor (vscode is using components, zed and nvim are both working on it), or plugin engines for a wide range of other applications (e.g. last year I consulted for cubist on https://cubist.dev/blog/introducing-programmable-key-management-policies, which also does use wasi-http internally), where components and wasi have tremendous advantages over existing solutions.
Alex Casalboni (Aug 13 2025 at 07:48):Thank you @Pat Hickey, this context is incredibly useful :pray:
Coming from an app development background, it's not immediately clear why these tradeoffs were taken, and the initial context of "why Wasm+WASI were initially designed this way" can get lost in the public documentation. And the (probably overhyped?) vision of "Wasm+WASI is becoming the next Docker" doesn't help either.
Pat Hickey (Aug 13 2025 at 15:00):Yeah, that one tweet by the docker guy hasnt really done us any favors.
Last updated: Dec 06 2025 at 05:03 UTC