Consider implementing the API for non WASM targets

[tomasol]

I am aware of #6 and understand that testing the component requires using wasmtime. However, it would be highly beneficial if waki could support running in non-WASM environments, wrapping one of existing HTTP clients.

This enhancement would allow developers to test and debug components using familiar tools, streamlining the development process and making it more accessible.

[iawia002]

Hi @tomasol sorry for the delay.

Wrapping an implementation for non-WASM targets isn't difficult, but I'm not sure if it makes sense. This is because the implementation for WASM is very different from a regular implementation. It's quite likely that something running correctly on a non-WASM implementation might not work on the WASM implementation, making debugging this way pointless.

[tomasol]

Do you think that the behavior of the HTTP client is going to be different all that often? Sure, the host could decide to do something else with the request, and in order to test that, one needs to write an integration test as suggested in #6, but for most cases I think it is safe to assume that the host will forward the request properly.
It could be hidden behind a feature flag to highlight the fact that this is intended for testing.

The scenario I am thinking about is introducing WASM Components to new developers. Not being able to use one of the standard clients (yet) is a hassle, so we should not add more things that look like a barrier.

[iawia002]

but for most cases I think it is safe to assume that the host will forward the request properly.

This is reasonable, but I haven’t figured out the specific implementation yet. It might not be a high priority for me at the moment. However, if you're interested, feel free to submit a PR.

[jzhn]

I would second this feature request.

First of all, great job to the author and maintainers to this repo, same as @tomasol , I came across this repo a few weeks ago, and surprisingly find that how much simpler it makes developing http clients and servers on WASM.

In addition to the testing purpose mentioned in the ticket, If waki can be made to work across WASM and non-WASM targets, it'll be very useful in libraries like Dapr SDKs. Nowadays, WASM developers need to rebuild many wheels simply because libraries like Dapr SDK can't work out of the box in WASM. A generic cross-target http client would help to resolve these cases.

I think the testing perspective is still valid - maybe it's inappropriate to unit test in native Rust because of the potential behavioural difference, but sometimes we want to write somewhat integration-level testing, taking Dapr client again as example, I'm hoping to use testcontainers to startup a datastore and Daprd container and validate that my client is sending the right headers to Dapr and it's able to CRUD the datastore. Mocking waki wouldn't make much sense in such test.

[k0pernicus]

Hi,
Sorry to be part of the conversation but I wanted to give you my thoughts about this.

First, thanks @iawia002 for this work.

I don't really understand why another target(s) should be added, as the project is targeting WASM applications for servers / non-browser-applications.
Imoo, If users want to get another target in their library or binary, then they can do using a cfg macro that targets their "target" (sorry), and incorporate another library for that.
Incorporating another target here will complexity, in my own opinion, both dev testing and the library specifications.
Especially if this library was planned, from the ground up, to be an experiment with a specific target.

I understand that using one and only one library for every target in the world could be interesting, but as WASM seems specific and is still in proposal I don't think we should make this project more complex.

[tomasol]

I agree that this may not be the right time for this endeavor. It would be best to wait until WASI 0.3 is released.

Regarding complexity, it has to exist somewhere. Centralizing it in one place is preferable to having multiple separate HTTP clients in every library that needs to support both native and WASI targets.