Proposing recommendations for libraries which use network crates

1

I think it is good to avoid using network libraries right in the library which performs the logic itself because of cargo dependency hell.

Let's start with example: urlshortener-rs. The library simply performs requests to the services for shortening links. It uses reqwest crate internally. However, in big projects it is very difficult to use many crates, and if this crate (urlshortener-rs) is used in a big project, there could be problems with network libraries, for example, with openssl: if the urlshortener uses openssl v0.7 crate and if the big project already uses openssl v0.9 crate, there will be a compilation failure.

I am thinking about abstraction the transport so that the user defines what to use in the urlshortener crate and not the library itself, since it may give problems. At first I thought "well, probably, the reqwest crate already is an abstraction of such a transport, but there is a problem still: the user project may already use another version of reqwest and there may arise problems again. Or, the reqwest may have another problems someday, and we are back to the same problem. So, I am gonna let the user decide what transport to use without limiting it to what I use in my library crate.

What do you think?

2

If I'm reading it correctly, you want similar to log but for networking.

Nice in theory, maybe a bit too broad in functionality to make practical.

3

I have run into a similar issue both with networking and with futures/tokio. My current opinion is that the features feature of cargo is the first step. You feature gate whether to use your own transport layer relying on whatever dependency you want. Otherwise, you can let people opt-out of that feature, but then they are required to pass in something that implements some transport trait with the necessary API that you need.

It would be nice to have a well adopted transport API, but it is easy enough to write your own wrapper to conform to whatever someone picks.