go-json-rest
go-json-rest copied to clipboard
ant0ine
Allow Multiple SetRoutes Calls
I have some optional bits of code in my app that enable or disable groups or routes dynamically. To realize this, I have to make my plugins generate lists of routes everywhere and then concatenate them in my initialization code.
While I can easily continue to maintain lists of routes (right now, I build a global list), I'd much rather consider the handler to be the "container" of the routes (much like net/http does with a ServeMux and handlers). This is pretty trivial, and I'd gladly write it if you'll accept the patch.
What are the usecases, just curious?
On Sunday, January 18, 2015, jcrubino [email protected] wrote:
+1 for this
— Reply to this email directly or view it on GitHub https://github.com/ant0ine/go-json-rest/issues/22#issuecomment-70442699.
I'm curious about this too.
A few thoughts:
-
Having all the routes defined at the same place is usually much easier to read and understand. I have a few examples of ExpressJS apps in mind where you have to "grep" the route definitions from a large piece of code in order to get the big picture.
-
Generating the list of Routes is an important use case. You may want to generate the CRUD routes of a set of objects, or using Swagger for instance. But the current SetRoutes method does not prevent that, it just forces to have the []Route slice built before calling it.
-
In any case it won't be possible to add routes after the initialization of the app. This is because this router is based on a trie data structure that is optimized for reads once all the routes are defined.
In the case of large apis being able to group routes into sets not necessarily declared in func main would be nicer to work with.
I have two primary use cases:
The first is library code. I have some common stuff shared through a few applications. I currently have my own, custom logic to collect the pieces and provide them all at once. I generally consider that low-value code. Given that it seems (to me) that it must be a common pattern, I'd expect the framework to have a way of doing it.
The second is code that turns on and off. I have some debugging end-points and an admin system for one app. It currently turn debugging on/off with a signal and disable the admin system from the command line. I do this by wrapping my code in a helper that responds to global flags set by the signal handler and option parsing code. While this all works, it's pretty low value code (and also, again, probably a common need).
In terms of the big picture, I think it's pretty powerful (and useful) to have the ability to flexibly compose routes. You get things like:
- Being able to graft one app under some path.
- Include common functionality into many apps.
- Automatically generate entire APIs.
In the general case, you can get a lot of mileage out of just being able to swap out the routes at runtime. Maybe instead of adding routes, it can just replace them, or regenerate them from registered route providers.
With respect to the trie not being easily modified, I don't think that we're ever talking about so many routes that it's not easy to just regenerate from scratch. As long as it's not happening every few seconds, I'd expect it not to be a (performance) problem to just do that.
I'm surprised this is so old and still open. I have a use case to dynamically add and remove routes at startup according to configuration. If I could append routes i'd be able to do that easily when certain "features" of my code are enabled.
