Potential confusion when updating from Axum 0.5 to 0.6 with ServeDir and correct router method use

[philpax]

Hi there! Opening a discussion because I'm not sure this is really an actionable issue, but just wanted to point it out as a potential hazard for others / something that could potentially be prevented with additional types.

In Axum 0.5, we had the following code:

let router = Router::new()
    .nest("/assets", get_service(ServeDir::new(project_path.join("target"))).handle_error(handle_error))

In Axum 0.6, the nest method no longer accepts get_service, which is a MethodRouter. I switched to route, because that's the first thing I saw that took a MethodRouter:

let router = Router::new()
    .route("/assets", get_service(ServeDir::new(project_path.join("target"))).handle_error(handle_error))

However, this leads to incorrect behaviour - the routing is wrong, and things will not behave as expected. The correct solution is to use nest_service:

let router = Router::new()
    .nest_service("/assets", get_service(ServeDir::new(project_path.join("target"))).handle_error(handle_error))

but I hadn't realised this until it broke. Would it be possible to more meaningfully disambiguate these so that you're "led" to the more correct solution by the type system? Of course, services can be arbitrary things so the additional flexibility probably makes sense - but I've personally found the route / nest[_service] distinction to be confusing in other contexts, too.

[davidpdrsn]

People accidentally using route instead of nest is relatively common I think. Would be good to help with that somehow, but I don't know how. Do you have any suggestions?

[philpax]

Honestly, I'm not sure - part of me wants to say that nest-by-default is the more intuitive behaviour, but I also recognise that would likely lead to unintuitive behaviour elsewhere. I think I've seen other frameworks more actively separate routes from subrouters, so that you have to use a different method for a subrouter and your application will fail to run [or compile] if you use a subrouter where a route was expected, but I imagine that doesn't really fit into the tower paradigm.

[davidpdrsn]

I think I've seen other frameworks more actively separate routes from subrouters, so that you have to use a different method for a subrouter

I mean axum does this already: route and nest.

The difference is that some methods accept S: Service which is quite broad.

[philpax]

Yeah, that's what I mean - route can implicitly accept "middleware" (even though there's no such distinction here), where that would normally be an error of some sort in other frameworks due to a more strict delineation between them. I don't think that could be made to work here, given the S: Service bounds.