macro-free routing vs attribute macro-based routing

[rockpunk]

Summary

Since Axum highlights a macro-free routing api as one of its top features, I am curious about the design choice about why Axum chose this in comparison to the attribute macro routing of Actix or Rocket. While macros certainly aren't necessary, I find that I rather like the self-documenting effect of the attributes (at least when looking directly at the handler code).

Example in Actix:

#[get("/")]
async fn hello() -> impl Responder {
    HttpResponse::Ok().body("Hello world!")
}

#[post("/echo")]
async fn echo(req_body: String) -> impl Responder {
    HttpResponse::Ok().body(req_body)
}

or Rocket:

#[get("/hello/<name>/<age>")]
fn hello(name: &str, age: u8) -> String {
    format!("Hello, {} year old named {}!", age, name)
}

What is the Axum take on why having no macros here is better? Are there cases where using macros in Actix/Rocket break down and the base Axum router is more scalable / maintainable? Thanks for the insight!

axum version

any

[mladedav]

I would say it's often just preference. I tried to use actix for one personal project, the. rewrote it to Rocket and then forgot about it, so I wouldn't say I have much experience with either.

But for me personally, the issue was finding a handler for a route I knew existed. With Rocket, you just put a bunch of handlers into routes![] macro and it works. So you end up with better discoverability of the routes when you have the function, but worse when you have the route and want to see the implementation.

I remember working around that by having the handlers named something like handlers::users::post. It's a solution but it can drift from real world easily.

[jplatte]

Personally, I find the macro-free API much more flexible. For example, people can build their own abstractions on top of the Handler trait, like aide's AxumOperationHandler.