middleware::map_request[_with_state[_arc]] and map_response[_with_state[_arc]]

[jplatte]

Feature Request

Motivation

axums from_fn[_with_state[_arc]] can be confusing to newcomers who haven't read about / fully understood tower's "onion principle" of layers yet. Its generality also makes for a little more boilerplate than necessary when one wants to write a middleware that only concerns itself with either the request or response.

Proposal

Add map_request[_with_state[_arc]] and map_response[_with_state[_arc]] to the middleware module. In the case of map_response* it is notable that async functions passed to these functions will never have to be generic.

Alternatives

Do nothing.

[davidpdrsn]

I think that makes sense to support. I'm a bit worried about duplicating stuff that is in tower but I think these two are probably fine.

[jplatte]

Well, ours are going to be more ergonomic by supporting extractors.

[davidpdrsn]

Oh yeah that's right!

[jplatte]

I've been discussing this a bit with @genusistimelord, one question that came up is what the function signature should look like, in particular for map_request*. For some use cases, you may want to return early inside the closure, so a Result<Request<B>, impl IntoResponse> return type could make sense. But then people who have an infallible closure have to write Ok::<_, Infallible>(req) because of the generic E type on the Result.

The easy way out of this is providing both map_request* and try_map_request*. For map_response, none of this is needed because that can just return any type that implements IntoResponse.

[davidpdrsn]

Maybe https://doc.rust-lang.org/stable/std/ops/enum.ControlFlow.html?

[jplatte]

Can you elaborate? That's pretty much just a different way of spelling the same thing (w/ some different rules for ?) and still leaves the question of whether there should be separate try_ variants or not, no?

[genusistimelord]

I think a map_request* and try_map_request* make the most sense here as we can dictate that map_request never fails and try Can fail returning a Result<Request<B>, IntoResponse> or a ControlFlow<IntoResponse> and make req passable via &mut req?

[davidpdrsn]

I was thinking something like #1408