[ab]use operator overloads for router and layers

[alexpyattaev]

Monitor punching warning, please consider removing sensitive people and children before proceeding

There are currently 3 main operations for constructing routes:

• route(path: &str, method_router: MethodRouter<S, B>) which inserts a MethodRouter for path
• nest(self, path: &str, router: Router<S, B>) which nests one router into another under path
• merge<R:Into<Router<S, B>>,>(mut self, other: R) which merges two routers together

Conceptually, however, both route and nest operations do essentially the same thing, roughly equivalent to

let new_router = base_router / "some/fancy/path" / HandlerThing(...);

Similarly, "merge" operation is (using a set-theoretic interpretation of the '+' operator) equivalent to

let new_router = base_router + other_router; 

The other thing we commonly do is adding layers, which are, in concept, a pipeline, and can be written as such:

let app = layer_one(...) | layer_two () | layer_three() | base_app; 

This would also address the somewhat misleading way how layers get executed in reverse order w.r.t. how they are listed in the code.

With some operator overload "magic" one could make all of these a reality.

Obviously, similar syntax may be enabled for the MethodRouter:

let router = router  / "some/object" / (post(handler) & db_handle + get(handler2) & db_handle );

The nice bit about this syntax is that one can use 'normal math rules' to expand the statement:

let router = base_router  / "some/object" / (post(handler) & db_handle) +
                    base_router  / "some/object" / (get(handler2) & db_handle);

I'm quite certain that with a bit deeper thinking this can be made even less clunky (e.g. using '&' operator for state is, probably, not the only sensible option), would be interesting to know what the others think before I put substantial effort into making it a reality.

There are a few obvious issues with this idea:

1. Some people just hate operator overloads for various reasons (i.e. all the Go users), so none of this should ever land into examples
2. This duplicates existing functionality (i.e. more than one "obvious way to do it")
3. This probably belongs in a separate crate, but given Rust's rules about trait definition, it would be tricky to do operator overloads without adding trait impls for axum's own structs. If someone has an idea how that could be achieved I'm all ears.

PPS: In terms of how hard this is to implement:

impl Add<Router> for Router
{
    type Output=Router;

    fn add(self, rhs: Router) -> Self::Output {
        self.merge(rhs)
    }
}

nest and route require an intermediate struct, but are still essentially trivial:

pub struct RouterNestyThing{
    r: Router,
    s: &'static str
}

impl Div<&'static str> for Router
{
    type Output = RouterNestyThing;

    fn div(self, rhs: &'static str) -> Self::Output {
        RouterNestyThing{r:self, s:rhs}
    }
}

impl Div<Router> for RouterNestyThing
{
    type Output = Router;

    fn div(self, rhs: Router) -> Self::Output {
        self.r.nest(self.s, rhs)
    }
}

Piping layers together would have to construct a ServiceBuilder, which, when piped with Router, would call .layer() on it. So, not hard at all.

[davidpdrsn]

Having used Scala and Haskell quite a bit, who are both into operator overloading, I'm thinking no 😅

By the way did you just read https://reddit.com/r/rust/comments/10golkq/six_fun_things_to_do_with_rust_operator/?

[jplatte]

I have only used Haskell of those two but I agree. Also I too thought "I know which article you read today" 😄

Doing this for real would just lead to unnecessary confusion IMO.

[alexpyattaev]

Of course I have read it :) And I totally agree that over-doing this sort of stuff is often a very bad idea™ and a first step on a road to Haskhell. However, I have changed a bunch of my own code to use it and I have to admit... it did feel nice by making the code way less "noisy". As I have mentioned, I'd love to have this as a crate, but I have no idea how to get around Rust's restriction on definition of traits on foreign types. Any hints there?

After some fiddling I could get this to work from "external crate":

     let app = OverloadedRouter::from(root()); // use ugly newtype 😭
    let app = app / "some_path"/ get_foo(); //enjoy nice syntax  😃
    let app = app + get_foo() + post_foo(); //and again  😃
    async fn handle_get()-> &'static str {"Hello!"}
    let app = app / "object/of/interest"/ get(handle_get); //and again  😃
    let app = app.0; // unwrap the original Router instance and 😭  
    axum::Server::bind(&addr).serve(app.into_make_service()).await.unwrap();// Serve, enjoy

However, the ergonomics are somewhat terrible (especially since a macro would be needed to actually pull all methods from Router into OverloadedRouter), and doing the same sort of stuff for layers is a whole lot trickier.

[jplatte]

I don't there's a much nicer solution than what you wrote. I'd probably make the inner field on OverloadedRouter private and provide .into_inner() rather than having users write .0, and add stuff like .into_make_service() as inherent methods as well.

[alexpyattaev]

Naturally, but it will still be super-clunky. I suppose, given how much interest is in this feature, this will have to wait until trait specialization is stabilized =) Thanks for all the advice!