http-client icon indicating copy to clipboard operation
http-client copied to clipboard

http-client's future

Open Fishrock123 opened this issue 4 years ago • 12 comments

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.

Fishrock123 avatar Aug 30 '21 17:08 Fishrock123

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.

yoshuawuyts avatar Aug 31 '21 14:08 yoshuawuyts

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

Fishrock123 avatar Aug 31 '21 18:08 Fishrock123

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

bugproof avatar Oct 01 '21 21:10 bugproof

Yes

Fishrock123 avatar Oct 04 '21 16:10 Fishrock123

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

bugproof avatar Oct 06 '21 17:10 bugproof

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

Fishrock123 avatar Oct 06 '21 18:10 Fishrock123

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 😄

bugproof avatar Oct 06 '21 21:10 bugproof

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

Fishrock123 avatar Oct 07 '21 16:10 Fishrock123

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

bugproof avatar Oct 07 '21 17:10 bugproof

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

Fishrock123 avatar Oct 07 '21 17:10 Fishrock123

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.

bugproof avatar Oct 08 '21 13:10 bugproof

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.

sagudev avatar Oct 18 '21 17:10 sagudev