refactor(client)!: use bitreq for both BlockingClient and AsyncClient#137
refactor(client)!: use bitreq for both BlockingClient and AsyncClient#137oleonardolima wants to merge 2 commits intobitcoindevkit:masterfrom
bitreq for both BlockingClient and AsyncClient#137Conversation
293c886 to
7d21272
Compare
Pull Request Test Coverage Report for Build 18927210446Details
💛 - Coveralls |
c03e04f to
fd63f37
Compare
fd63f37 to
4b0dbd0
Compare
6ba4aad to
5b989db
Compare
|
@oleonardolima Any update here? The |
@tnull I didn't follow the recent changes for the latest bitreq release, do you deem it production-ready and with the feature-parity that we need from reqwest here ? |
Yes, we made good progress there (full/fixed async support, added a |
26dfb35 to
e9d41e0
Compare
- update the `BlockingClient` to use `bitreq` instead of `minreq`
- update the `AsyncClient` to use `bitreq` instead of `reqwest`
e9d41e0 to
1337d8e
Compare
bitreq for both BlockingClient and AsyncClient
|
@tnull I did an initial shot on this one, it's pretty straight-forward so far. However, there's still some API changes I'd like to do, mainly trying to unify it into a single client. Also, I didn't throughly tested it yet, specially in wasm environments. Also, I'm wondering if it'd be best to wait for the |
| /// Perform a raw HTTP GET request with the given URI `path`. | ||
| pub fn get_request(&self, path: &str) -> Result<Request, Error> { | ||
| let mut request = minreq::get(format!("{}{}", self.url, path)); | ||
| let mut request = bitreq::get(format!("{}{}", self.url, path)); |
There was a problem hiding this comment.
Hmm, it's kind of unfortunate we don't have a Client for the blocking variant, as this means we'll establish a new connection for each request. Maybe we might first need to add it? I can give it a shot in some time this week, so this would be unblocked?
There was a problem hiding this comment.
Yes, that'd be a good improvement.
No description provided.