Seeking guidance on middleware stack usage before routing in Axum

[NuclEnergy]

Summary

Description

I'm trying to ensure certain middlewares (e.g. rewriting uri, logging, CORS) always run before Axum's router attempts to match incoming requests. The main reason is that if routing fails (no matching path), the request is immediately returned with an error response, and none of my desired middlewares get a chance to run.

However, I'm running into a couple of issues around the type system when stacking middlewares:

1. If I build a middleware stack that includes layers like TraceLayer, CompressionLayer, or custom rewriting, I run into compilation errors about mismatched service types.
2. Those errors persist until I introduce either:
   • An "empty" custom middleware (e.g. using axum::middleware::from_fn), or
   • An explicit call to .map_request_body(axum::body::Body::new) & .map_response_body(axum::body::Body::new).

In both cases, these solutions feel a bit awkward or heavy-handed. I'm not completely sure if I'm misusing Axum’s or Tower's layering system, or whether these “workarounds” might have unexpected runtime consequences.

Below is a simplified excerpt from my code:

async fn my_middleware(req: Request, next: Next) -> Response {
    next.run(req).await
}

#[tokio::main]
async fn main() {
    let middleware_stack = ServiceBuilder::new()
        // Attempt to unify types:
        .map_request_body(axum::body::Body::new)
        .map_response_body(axum::body::Body::new)
        // or using a custom from_fn middleware
        .layer(axum::middleware::from_fn(my_middleware))
        // Some middlewares I'd like to run no matter what:
        .layer(NormalizePathLayer::trim_trailing_slash())
        .layer(CompressionLayer::new())
        .layer(
            TraceLayer::new_for_http()
                .make_span_with(DefaultMakeSpan::default().include_headers(true))
                .on_request(DefaultOnRequest::new().level(Level::INFO))
                .on_response(DefaultOnResponse::new().level(Level::INFO)),
        )
        .layer(cors_layer());

    let listener = TcpListener::bind("127.0.0.1:3000").await?;
    let app = Router::new();
    let service = middleware_stack.service(app);

    axum::serve(listener, service.into_make_service()).await?;
}

If I omit the calls to map_request_body & map_response_body, the compiler complains that the final service type doesn’t match what Axum expects. Alternatively, I can prepend an empty from_fn middleware that simply does next.run(req).await, and that also makes the type errors go away—again, feels unintuitive.

Questions

1. Am I using Axum or Tower incorrectly by wanting these middlewares to run before routing?
2. Is there a more elegant or canonical way to ensure certain middlewares are invoked regardless of whether or not there’s a matching route, without resorting to an empty custom middleware or forced map_request_body&map_response_body calls?
3. Could these workarounds introduce any undesirable runtime side effects or performance issues?

I’d really appreciate any best-practice recommendations or clarifications on how Axum 0.8.x is intended to handle these kinds of global pre-routing middlewares in a more idiomatic way. Thank you in advance!

axum version

0.8.1

[mladedav]

1. No, this is correct and supported way to run middlewares pre-routing. However, I don't think I've seen other usage than NormalizePathLayer yet. You said you're doing this so that the layersrun even if they do not match a path. So the simplest thing you could do is to put all but the NormalizePathLayer as layers inside the Router. Of course you might not want to do that for some reasons, e.g. to have tracing called before the path normalization.
2. Yes, just doing Router::new().route(...).layer(CompressionLayer::new()) should work. Feel free to ask another question if it doesn't for you.
3. Yes, but I don't think they would be too bad. I think that the request mapping should do nothing (there's some downcasting involved) but the response mapping would box the response body. How bad that would be depends on whether you stream your responses and if they're large but I don't think it would be that bad.

---

Bit more details about the two approaches you came up with (on which I commend you by the way, I don't think I'd come up with the from_fn approach).

What axum::middleware::from_fn does in the background is something like this (assuming no extractors like in your case)

        .layer(tower::layer::layer_fn(|inner| 
                    ServiceBuilder::new()
                        .layer_fn(tower::util::BoxCloneSyncService::new)
                        .map_response(axum::response::IntoResponse::into_response)
                        .service(inner)
        ))

where the map_response call is pretty much the same thing as .map_response_body(axum::body::Body::new) and the service boxing is not needed in this case, it just seems to help with resolving the Request type for some reason.

But you could change the axum::serve call instead to

    let make = ServiceExt::<axum::extract::Request>::into_make_service(service);
    // let make = ServiceExt::into_make_service(service);  // <- doesn't work, we need the type hint

    axum::serve(listener, make).await.unwrap();

When you give the explicit type, the request mapping is not needed anymore.

As for the response mapping, I don't think you can really get around that right now because axum::serve expects that the service returns Response<axum::body::Body> but CompressionLayer and TraceLayer change the type. We might try looking into relaxing this bound.