Closed morenol closed 3 years ago
I was thinking of hyper for the async side of things, and expose the Executor, so that anyone could even use their own custom executors if they want to. Ofcourse we could provide tokio, async-std and smol as cargo features.
For the blocking side of things, ureq might be a good option.
That sounds great! We should keep an eye in adding support to WASM.
I could start working on the lower level client.
An idea for the internal API that I have come up with:
/// A hyper client with pluggable Connectors and Executor
type HyperClient<C> = hyper::Client<C, hyper::Body>;
/// A WASM client
struct WasmClient {
// ...
}
/// A Blocking Client
type BlockingClient = ureq::Agent;
I'll probably wrap them up rather than rexporting them as types, with custom functions with similar names to be used for different clients. Is this a good ides? Is there a better approach to tackle this.
I like the idea that is done in the elasticsearch client of Rust, where they have a HTTP low level struct called Transport, and they create the high level Client with that.
They have a TransportBuilder to create that.
What do you think about that approach?
We could make Transport a trait and implement that for the WasmTransport and HyperTransport structs (?).
Yeah this seems like a good option.
Closed by #8
Description
reqwest, surf, isahc, other?
In the python library these are the http calls that are being used:https://github.com/typesense/typesense-python/blob/c0592c8936540397d436d92b634cc40005c42a69/typesense/api_call.py#L135