This is really exciting - I really like the design so far.
In particular I love the focus on “plain Rust”. I think this could be really valuable for those of us who want to build something more complicated than “hello world” examples and want to be able to customise/offload behaviour into the framework, but don’t have PhDs in type theory or AST manipulation.
I’m a fan of the simple path+method routing, I think it makes it super easy to see what routes exist in the application, and which handler each maps too. The nested routers seem like a nice touch too.
I may be an outlier here, but I also like the lack of fallbacks - in my opinion it results in far fewer surprises, especially if many people are working on an application. I don’t mind having to use
Option<Auth> and an extra if statement if it reduces the amount of magic in the application.
I’m not against the idea of type safety on path params in principle, but I would be nervous that trying to make it 100% compile-time safe could end up overcomplicating the design. There’s also a risk of losing the route in the noise, which I think is one of the flaws in the Warp approach.
That said, perhaps being able to name the path params might help describe a route’s intent, even if the name isn’t used for anything else. eg.
I think the combination of
IntoResponse could end up being really powerful. I’m imagining you could, for example, create a
RequiresAuth<User> extractor which could check if the request has a valid auth token and then either populate the User and continue, or automatically redirect to the login page. Or you could have an
IntoResponse which does content-type negotiation to decide whether to return, say, json or xml.
All in all, I’m really looking forward to having a play with this and finding out more about the middleware/extensibility story.