Add bitreq

[lescuer97]

Description

use bitreq for the non wasm targets and use reqwest for wasm. in the http client crate.

---

Notes to the reviewers

---

Suggested CHANGELOG Updates

CHANGED

ADDED

REMOVED

FIXED

---

Checklist

• I followed the code style guidelines
• I ran just final-check before committing

[crodas]

@lescuer97 almost there, I think we should remove reqwuest all together and use this bits for wasm, using the native "fetch" function provided by the browser and bitreq for everything else

[thesimplekid]

@lescuer97 almost there, I think we should remove reqwuest all together and use this bits for wasm, using the native "fetch" function provided by the browser and bitreq for everything else

I don't think we should remove reqwest all together. Can't we make use of a trait and then implement that trait for both bitreq and reqwest, it should only have a couple fns. We can then feature flag these implementations. Many projects already use reqwest so use reqwest within cdk would not be adding any deps and in fact using bitreq would. This would also make it easier for us to switch between the two as bitreq is still new we could encounter issues.

[lescuer97]

@lescuer97 almost there, I think we should remove reqwuest all together and use this bits for wasm, using the native "fetch" function provided by the browser and bitreq for everything else

I don't think we should remove reqwest all together. Can't we make use of a trait and then implement that trait for both bitreq and reqwest, it should only have a couple fns. We can then feature flag these implementations. Many projects already use reqwest so use reqwest within cdk would not be adding any deps and in fact using bitreq would. This would also make it easier for us to switch between the two as bitreq is still new we could encounter issues.

projects already using reqwest is true. I had not think about it

[crodas]

The reqwest feature needs to be added to the cdk and perhaps the mintd crates as well, since the http crate is not injected or cannot be provided externally.

[thesimplekid]

mintd we can just make the choice we don't need to give a feature.

[thesimplekid]

Even if we do not provide the feature externally, I still think it makes sense to do as a trait. Since we know we will have at least 2 impls even if we drop reqwest wasm and native.

[lescuer97]

okey, just to clear thing up. I will then keep this code but add back the features for bitreq and reqwest.

and reimplement the trait for reqwest.

does this sound correct?

[crodas]

I can help if you want, but I also believe the trait is a good idea and it should live in cdk-common perhaps.

[thesimplekid]

I just remembered we actually have 3 at minimum due to Tor. We already have a trait there maybe we can just move it and consolidate?

cdk/crates/cdk/src/wallet/mint_connector/transport/tor_transport.rs

Line 225 in 48e5002

impl Transport for TorAsync {

[lescuer97]

@thesimplekid @crodas just to be clear on what to do next. I should keep the trait that already exists in the http package, then use that trait for the tor implementation also. possibly moving that code into the http crate.

plus go back to use features. so users can decide to use either the reqwest or bitreq trait.

[thesimplekid]

We want to move the transport Trait to the http crate. Tor, bitreq and reqwest should all implement this each behind a feature in the http crate. The MintConnector should stay roughly the same in cdk where it takes the Transport trait.