http-client's future

[Fishrock123]

For Surf 3.0 I am almost certainly going to merge http-client back into it. The feature flag mess currently is hellish and maintaining it is a bad experience. Most of this would be solved by not having surf set downstream feature flags.

If you use http-client for a client other than surf you either need to step up and help me maintain this or lose it. Thanks.

[yoshuawuyts]

Yeah that makes a lot of sense. Do you have a sketch of what that API would look like? I'm still interested in eventually implementing a win32-native HTTP client backend. Getting a sense of what that would look like under this model would be nice.

[Fishrock123]

I don’t think anything would change other than the removal of the intermediate crate.

[bugproof]

Does that mean surf will replace http-client? I'm kind of confused right now.

[Fishrock123]

Yes

[bugproof]

Oh but Surf only supports async-std. I think that defeats the purpose of http-client crate.

[Fishrock123]

You can still run surf with the hyper backend...?

[bugproof]

Dependency doesn't seem to be optional https://github.com/http-rs/surf/blob/main/Cargo.toml#L67 or maybe I misunderstood something. I'm not that experienced in Rust 😄

[Fishrock123]

Do you actually use http-client for something that is not Surf and if so, what is it?

[bugproof]

I planned to use it as an abstraction for API client libraries to avoid coupling them to specific async runtime and HTTP client.

[Fishrock123]

Then you will need to help me maintain http-client. As I said, the feature flag situation with Surf is quite poor right now, and development is just overcomplicated by having this be a separate library.

surf with an http-client-only feature would probably be better or something

[bugproof]

How would this be solved if http-client was merged into Surf? You would need to create a separate surf crates for each HTTP backend no? surf-hyper, surf-curl to solve feature flag situation. Unfortunately feature flags in Cargo aren't solved in very elegant way. I try to avoid using them whenever I can. If you could remove a direct dependency on async-std in Surf then I guess it would be a fine alternative to http-client traits.

The problem with Rust right now is that the async ecosystem is pretty much an opinionated mess and many api client libraries just choose 1 http client for the job, mostly reqwest which uses tokio under the hood.

It doesn't give a lot of freedom with async runtime choice and feature flags is mostly just additional boilerplate code that's hard to maintain. What users of these libraries can do is either move to the supported runtime, write their own library or fork the existing library and replace the runtime or add support to another runtime via feature flags.

[sagudev]

Upcoming Rust 2021 edition will also solve some of feature flags hell. If I am not mistaken resolver 2 can be explicitly used from older versions of rust.