Add Tokio ecossystem support about unleash-client-rust HOT 9 CLOSED

Another option would be to give the user the option to provide their own HTTP implementation, which would make this crate runtime-agnostic.

from unleash-client-rust.

My current opinion is that a good approach here would be to make the http field in Client generic and bounded by a trait UnleashApi. This crate then could keep exposing the surf-based implementation of the trait (that is enabled based on a cargo feature).

At first, I though that a simple switch of implementation based on feature would suffice, but users may have special needs that the default implementation wouldn't support (e.g. at our codebase, we only use rustls for TLS, we don't have openssl as transitive dependency). However, having a trait that the user can fully implement give them more flexibility (a specific user-case that came in my mind now are temporary authorization tokens when implementing custom authorization, which right now would require re-creating the client when the token changes).

from unleash-client-rust.

Thanks @luisholanda. I'll bring this up with the team today, will get back to you shortly.

from unleash-client-rust.

Github Issue: Rust client dependencies

from unleash-client-rust.

Hi @luisholanda, thanks for the inputs here. I can very much see how pulling in a ton of dependencies that you neither want nor need is problematic. I like the suggestion you make about allowing the possibility to provide a custom HTTP client implementation, it sounds like between that and gating the async runtime that would solve your problems while making minimal adjustments to the way the sdk works at the moment. If you'd be willing to do a spike on this, I would love to take a look! Would also be great to @rbtcollins inputs on this too

from unleash-client-rust.

I think bring your own would be a bit enthusiastic right off the bat, let's treat that as a separate feature.

I have no issue just migrating to tokio, surf was arbitrary... as long as what we move too has no hard dependency on the runtime (since that would make us unusable for async-std or smol). Surf today has that property of no runtime dependency.

If there are no such clients in the Tokio ecosystem, then yes, features for each and surf as default.

from unleash-client-rust.

I have no issue just migrating to tokio, surf was arbitrary... as long as what we move too has no hard dependency on the runtime

Ok! I'll do some experiments today to see if I find something that we can use without having to create a bunch of features.

If you'd be willing to do a spike on this, I would love to take a look!

I'll see if I can do a prototype later this week.

from unleash-client-rust.

I didn't find a HTTP implementation that would solve the dependencies problem for all runtimes, so I decided to go with implementing separated features in #31.

Testing the changes in our codebase with the reqwest-client-rustls feature, only 7 new transitive dependencies were added, all making sense.

from unleash-client-rust.

This should be resolved for you, in main at least.

from unleash-client-rust.