Closed russcam closed 4 years ago
The Sender
trait is gone in #21, now that send()
is async, because async traits are currently not supported.
One potential improvement that may be made to the API is for builder structs to implement the Future
trait, such that .await
can be called on the builder and removing the send()
fn. Something like
let search_response = client
// Value is the request body type
.search(SearchUrlParts::None)
.body(Some(json!({
"query": {
"match_all": {}
}
})))
.allow_no_indices(Some(true))
.await?; // no explicit .send() before hand
This is similar to Async Builders and Async Finalizers. One wrinkle to iron out would be determining where the request data is constructed; this may be OK to move to the poll()
function in the Future
impl.
I’m going to close this issue for now; we’ve settled on the fluent builder approach.
The current implementation implements APIs as structs that follow the consuming builder pattern, mutating
self
when functions are called to set values. For example,Each builder
struct
also implements theSender
trait, a terminal function for sending the actual request, which consumes (transfers ownership of) the builderThis allows for the following usage pattern
An alternative implementation considered would be for API functions to accept a function parameter where the argument is the builder
struct
. For exampleThis would remove the need for each builder to implement the
Sender
trait, and the explicitsend()
function to execute the request. It would however make it trickier to compose default values for a request and use it as the basis for multiple requests. For example,Interested to hear technical arguments for each approach.