Better routing API #47

New issue

Closed

opened 2023-12-27 10:45:55 +01:00 by Jef Roosens · 1 comment

Jef Roosens commented

2023-12-27 10:45:55 +01:00

Owner

The API for defining routes is still a bit lacking right now in my opinion.

I'd like to add the concept of a router, a group of routes that can be mounted together at a specific subpath. Each of these routers can have the concept of "global steps", namely steps that get executed before a route's specific steps. This could be used to automatically add rate limiting or authentication to multiple routes at once. Routers should be able to get nested; this way the global router could be exposed as the API for adding all other routers. Of course we should account for routing conflicts.

These routers can then be added to the HTTP loop, where they will be merged into one large routing scheme (I don't think there's a need to keep this abstraction inside the loop, it's just for ease of use for the user).

The routing code itself is also not optimal; I'd like to switch from RegEx and going over a list of elements to a trie-based approach that supports :key and *keys, e.g. /example/:test would match /example/hello and /example/world, with these variables being exposed to the user by name using some API.

The API for defining routes is still a bit lacking right now in my opinion. I'd like to add the concept of a router, a group of routes that can be mounted together at a specific subpath. Each of these routers can have the concept of "global steps", namely steps that get executed before a route's specific steps. This could be used to automatically add rate limiting or authentication to multiple routes at once. Routers should be able to get nested; this way the global router could be exposed as the API for adding all other routers. Of course we should account for routing conflicts. These routers can then be added to the HTTP loop, where they will be merged into one large routing scheme (I don't think there's a need to keep this abstraction inside the loop, it's just for ease of use for the user). The routing code itself is also not optimal; I'd like to switch from RegEx and going over a list of elements to a trie-based approach that supports `:key` and `*keys`, e.g. `/example/:test` would match `/example/hello` and `/example/world`, with these variables being exposed to the user by name using some API.