Future router features

[Madeorsk]

Hi!
I'm currently discovering zzz and tardy and I love these! I have improvements suggestions about the router, and I would like to read your thoughts about them to know how I could contribute.

• I think the router should be an interface (something in the shape of the Allocator): this would allow to make third-party routers for zzz.
• The server / router API is missing a serve_error, which could allow users to define a custom renderer for errors in handlers, but also routing.
• When I was learning zig, I wrote a router for zap: zouter. With this router, you can define errors / not found handlers at any level of the routing tree, which allows users to define different handlers for different groups: for example, you can define an error handler for /api which renders errors as JSON, and an error handler for the rest which renders errors as HTML.
• About route parameters, I think named parameters are easier to use when writing a handler. I also think that a more flexible approach than the current TokenMatch implementation would be to allow regex instead of relying on types parsing. If you expect an integer, instead of using "%d", you'd write something like ":param([0-9]+)" (my inspiration for this comes from Flight for PHP). All captures would then be strings and the conversion (in case of an integer) must be made by users, but I don't think it's a problem...

For these last two points, it can also be answered this way: do you want zzz to provide a tiny simple router and let more complex tasks for third-party routers, or you want zzz to provide a full-featured router?

I'd be happy to open issues / pull requests with your wishes about the future router features, let me know! :-)

[mookums]

Hello,

The Router generally needs work and was put together fairly quickly just to get the job done. This is a good discussion to have now since I've been meaning to come around and get some work done on the Router/Routes.

1. The reason I've avoided doing things like interfaces is because I want to have a centralized common approach to using zzz. I'm trying to avoid the million ways to do the same thing problem with zzz (and tardy). There are a lot of things I've omitted due to this and ideally the obvious solution to be the most performant one for end users.
2. serve_error would be nice. In addition to this, there are two major things I want for the Router. I want the RoutingTrie to be generated entirely at comptime. All of the Route information is already know at comptime and the only things we get dynamically are the matched slugs in the URLs. I would also love to have middleware support as it makes complex routes so much easier to write.
3. With regards to route parameters, I don't mind having named parameters but I'd like to avoid regular expressions. I think this can also be solved with a comptime RoutingTrie as you would be able to generate a struct that represents the captures of that Route and pass it down to the handler and extract exactly what you need.

The general goal is to add features while minimizing the performance impact from having better ergonomics.

If you want to work on something, feel free to and I'll do my best to answer any questions you have! I'm likely going to take a look at this stuff pretty soon.

[Madeorsk]

I've started to work on a fully comptime-known router with the same features as what's currently implemented on main: https://github.com/Madeorsk/zzz/tree/comptime-router

There's one thing that cannot stay with comptime-defined routes: their data parameter. To be more precise, it can stay, but it must then be comptime-known, so there's no point to keep it (comptime-known values can be referenced without being passed like that). To allow routes to use runtime-known values, we must pass the pointer to the router instance (which is runtime), which could then pass it down to the route handler. I think it's not a problem, but it's a clear regression because instead of having separated custom data for every route, we would now have only one "big" custom data pointer.

Here's how routes definition currently look like on my branch:

var router = try Router.init(allocator, &[_]Route{
    Route.init("/").serve_embedded_file(http.Mime.HTML, @embedFile("index.html")),
    Route.init("/hi/%s").get({}, hi_handler),
    Route.init("/redirect").get({}, redir_handler),
    Route.init("/post").post({}, post_handler),
});
defer router.deinit();

[mookums]

Thanks for starting work on this! That snippet feels like a positive step in terms of the Router.

In terms of data per route, you are correct that it is a feature regression but not a significant one. Like you stated, the approach we will likely take will be passing in an AppState that is shared across all of the handlers and is accessible through the context.state or some variation of that.

Whenever it is ready, feel free to make a PR and I can take a deeper look into it.