[RFC] Revisit jester architecture: expose router class

[yglukhov]

There are already some feature requests that I can't see a good fit in the current architecture as currently jester more looks to me like a demo of fancy nim capabilities rather than full blown (micro) framework, even though we're using it in production =). The following architecture suggestion will make jester much more flexible, extensible and reusable IMO:

Do a Router class which is essentially a mapper_and_dispatcher of Requests to Handlers with smth like the following interface:

proc add*(router: Router, method: HttpMethod | string, urlPattern: string, callback: proc(r: Request): Future[void]) # adds handler to the pool. Lowest-level variant
proc remove*(router: Router, method: HttpMethod | string, urlPattern: string) # Removes the handler
proc dispatch*(router: Router, request: Request) {.async.}

The other higher-level bits of API should now be trivial to implement on top of that.
Overall this would allow using the router (which is IMO the key part of jester) in a custom server, split handlers across files and routers, use several routers per single server, create authentication/session handlers and similar request preprocessors/postprocessors, etc.

Does it make sense?

[dom96]

Makes sense. Hopefully soon I can stop neglecting Jester :)

[dom96]

There is now the ability to register multiple matchers. Matchers are called on all requests and are expected to perform their own routing.

[yglukhov]

Cool!

[dom96]

I think this will work as "middleware support" too. I'll add remove and dispatch too once I need them, if you still need them let me know.