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?