Add middleware::from_fn for creating middleware from async fns

[davidpdrsn]

I feel axum is in a pretty good place in terms of ease of use. However one area that is still a big hurdle for some people is tower::Service which quickly comes up up when writing custom middleware. Suddenly you cannot use high level async/await syntax anymore and have to worry about pinning, poll_ready, and most likely lots of generics.

This is something I've been thinking about for awhile but hadn't found a good solution for. But today I discovered poem's middleware_fn which I think is perfect for this!

So this PR introduces axum_extra::middleware::from_fn that works like this:

use axum::{
    Router,
    http::{Request, StatusCode},
    routing::get,
    response::IntoResponse,
};
use axum_extra::middleware::{self, Next};

async fn auth<B>(req: Request<B>, next: Next<B>) -> impl IntoResponse {
    let auth_header = req.headers().get(http::header::AUTHORIZATION);

    match auth_header {
        Some(auth_header) if auth_header == "secret" => {
            Ok(next.run(req).await)
        }
        _ => Err(StatusCode::UNAUTHORIZED),
    }
}

let app = Router::new()
    .route("/", get(|| async { /* ... */ }))
    .route_layer(middleware::from_fn(auth));

You have pretty much the same level of control as with tower::Service but with a higher level API.

[davidpdrsn]

I also considered calling this Rest but went with Next since its more common across other frameworks such as tide.

[davidpdrsn]

Also worth noting that for simple middleware tower's map_request, map_response, etc, utilities gets you must of the way there but its not easy to write something like the auth middleware shown in the PR description without a custom middleware since you need to return early.

extractor_middleware would also work but that has other limitations that middleware::from_fn doesn't have, such as access to the response.

[jplatte]

That's quite a long list of constraints ^^

I wonder what cursed middleware one could write that actually makes use of the extra capabilities FnMut gives in addition to "plain" Fn 😅

[davidpdrsn]

Hehe yeah 😜 I'm not sure FnMut is that useful in practice actually but since we a &mut self I figure why not. Tower also uses FnMut.

[johannescpk]

Probably a naive question, but how would one pass some context variables into the middleware function? I've tried wrapping the middleware itself into a "factory function", but failed to do so because of the B generics requirement. Basically something like

pub fn auth(some_context_variable: Context) -> impl Fn(Request<_>, Next<_>) -> impl IntoResponse {
    |req: Request<_>, next: Next: <_>| async move {
        // do something based on `some_context_variable`
        Ok(next.run(req).await)
    }
}

[davidpdrsn]

@johannescpk You can do this:

use axum::{http::Request, response::IntoResponse, Router};
use axum_extra::middleware::{self, Next};
use std::net::SocketAddr;

#[derive(Clone)]
struct Context {}

#[tokio::main]
async fn main() {
    let ctx = Context {};

    let app = Router::new().layer(middleware::from_fn(move |req, next| {
        foo(ctx.clone(), req, next)
    }));

    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));
    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .await
        .unwrap();
}

async fn foo<B>(ctx: Context, req: Request<B>, next: Next<B>) -> impl IntoResponse {
    next.run(req).await
}