Waiting for feedback on #450: should I try to generalize it for
FnOnce(&mut State) -> .../FnOnce(&State) -> ...? for returning IntoResponse instead of a Result? try handling sync and async in the same function? try making into_handler_error not needed?
With #438 it should be possible to ask for an
anyhow::Result<T> instead of Result<T, HandlerError>, that would allow for using ? directly
ok well
HandlerError implements the Error trait which doesn't make life easier but I guess we could implement a new struct as a wrapper that can implement From<E> for E: Error, basically as anyhow::Error does, but have a with_status method (and map_err_with_status or similar to make the use of ? convenient)
re
.to(handler) vs .to_async(async_fn). I tried making them the same function but you can't. With .to(), the handler's return type is a struct (either Box<_> or Result<_>). You can put two blanket impls for IntoHandlerFuture (or whatever we called it) and they are guaranteed to not collide, because they're implemented over structs.
with asyncfn, the return type is impl Future<>. You can't put a blanket impl from
impl Future<_> and Result<_>, because the upstream rustc maintauners could come along in std and impl Future<_> for Result<_>
so the compiler only lets you have one blanket impl if it's over a trait.
</lunch>
technic93 Do you have any ideas about running async tests? I tried it out with actix framework and their TestServer, and it works. The idea is instead of running each request with block_on wrapper, the whole test function is wrapped inside runtime. Then I can do await in the tests.
technic93 * Do you have any ideas about running async tests? I tried it out with actix framework and their TestServer, and it works. The idea is instead of running each request with block_on wrapper, the whole test function is wrapped inside runtime. Then I can do await in the tests.
P.S. I also wanted to see how matrix bot works 🙂
#438 is waiting for a review from @nyarly or @colinbankier but my experience with gotham shows that it might take several month before that happens
Does #438 intentionally not touch
HandlerError?
My main goal with #438 was to remove the outdated
failure crate and fix the NewMiddleware error types
any idea/suggestion on how I should change
HandlerError?
I'll have a look at that tomorrow if its possible to incorporate that into #438
A stupid question. If we merge #450, we'd have both a
to_async method for handlers taking State by value and to_async_borrowed one for by-unique-reference handlers. Do we want to have both or to change to_async into the borrowed version? If both, which should be the preferred one?
I would be in favour of
to_async and to_async_moved, or just drop the moved variant (people can mem::replace() if they need the owned version) . I tried desparately hard to make a borrowing version of to_async when I was writing it, but I was just not clever enough. to_async is new in the 0.5.0-rc1 release, so it might be acceptable to break its api before 0.5.x.
the other thing that is worth thinking about is whether it is possible to say
I have a similar thread open with the Goose maintainers in tag1consulting/goose#94 , and they mentioned that their original async callback implementation only accepts function pointers (not closures) but it's looking likely that this helper-trait approach will allow closures as well. Would be good to include an example that uses a closure as a route hander, if it's possible.
.to_async(|state| async { Ok("seems fine") } (or however that's spelled).I have a similar thread open with the Goose maintainers in tag1consulting/goose#94 , and they mentioned that their original async callback implementation only accepts function pointers (not closures) but it's looking likely that this helper-trait approach will allow closures as well. Would be good to include an example that uses a closure as a route hander, if it's possible.
2 replies
Hey! I'm creating an async/await JSON API, and I've got this boilerplate for every method. Seems incredibly excessive. Am I missing something?
let body = body::to_bytes(Body::take_from(&mut state)).await;
let request = match body {
Ok(r) => match serde_json::from_slice::<models::AuthParametersRequest>(r.as_ref()) {
Ok(r) => r,
Err(e) => {
return Err((
state,
e.into_handler_error().with_status(StatusCode::BAD_REQUEST),
))
}
},
Err(e) => {
return Err((
state,
e.into_handler_error().with_status(StatusCode::BAD_REQUEST),
))
}
};
@jcdickinson Don't remember whether the owning
to_async supports ?, but the to_async_borrowing from #450 tries to.
Hi. Is there anyway I could get the client's ssl certificate inside a midleware when using client side tls auth? This would only be possible with openssl, but I see the openssl create exposes
SslStream which has a ssl method that returns SslRef with the information I need, but I cannot see a way to get a SslStream inside a midleware. Could I somehow add that ref to State ?