Unable to use SDK with build target `wasm32-wasip1` & `wasm32-wasip2`

[aturingmachine]

Description

Attempting to include the flagsmith crate in a project that has a build target of wasm32-wasip1 (or wasm32-wasip2), will cause the build to fail.

Version Information

• flagsmith = "~2.0.0"

Reproduction

• I have made a minimal reproduction showcasing the issue if it is at all helpful.

Cause

flagsmith makes use of the blocking feature of the reqwest crate, as seen here. reqwest cannot be compiled with the blocking feature enabled in async environments (see reqwest issue #891), this means flagsmith cannot be used when targeting wasm32-wasip1.

Desired Outcome

I am admittedly unaware of how important the use of reqwest::blocking is for the flagsmith crate, or if it could be updated to use the non-blocking reqwest client - however that would be the best case scenario.

If that is not possible, adding something to the documentation of flagsmith stating that it cannot be built to target wasm would possibly help someone some time in the future if they are attempting to make use of flagsmith while targeting wasm.

[matthewelwell]

Hi @aturingmachine - thanks for raising this and I apologise that you had this experience trying to integrate the Flagsmith SDK into your WASM application. I'm a Flagsmith maintainer, but I've not spent much time looking at the Rust SDK. From a quick look however, I can see that reqwest::blocking is fairly heavily used throughout the SDK so we'll have to look into it in a bit more detail to understand what we can do to remove it (if possible).

One of the Flagsmith Rust developers will take a look as soon as they can and get back to you here.

In the meantime, you are free to use our API directly if you need to integrate Flagsmith into your application. See the docs here.

[aturingmachine]

Thanks! I am thinking any work that would need to be done to support wasm would be pretty heavy to get support for all the bindings, but I will wait for someone more experienced than myself to make that call.

In the meantime I will look into the direct integration.

[gagantrivedi]

Thanks! I am thinking any work that would need to be done to support wasm would be pretty heavy to get support for all the bindings,

Yep, you're pretty spot on with this! We’d definitely like to support WASM, but it’s not currently part of the backlog. That being said, we’d be happy to review and merge something if it’s something you’d like to contribute.

[aturingmachine]

Our specific use case is running on fastly's Edge Compute, which runs WASM, and I believe I have resolved our use case by swapping reqwest for the Request struct from the fastly crate in a local fork of the SDK. Its not tested, but it is compiling.

[gagantrivedi]

Yeah, I was planning to do that eventually. We're also exploring a use case for running our Rust SDK on Fastly Edge Compute. As I said, please feel free to create a PR and we can take it from there.

[aturingmachine]

@gagantrivedi Apologies for the radio silence on this, things got a bit hectic.

I've opened #33, contains the sort of "base" work for getting the crate to compile and an abstraction over reqwest and fastly::http. The description of the PR is much more detailed, and I would welcome any discussion on its implementation.