I like the notion/notation of a resource graph and will use it in the future :)
On Mon, Jun 19, 2017 at 12:31 AM, Kevin Conway <kevinjacobcon...@gmail.com> wrote: > > That being said, having access to easy-to-use, parameterized routes makes > things much simpler IMO. It cleanly separates the logic required for > resource graph traversal from the endpoint rendering. > I don't think that's mutually exclusive with what I'm proposing. Indeed, ServeHTTP can contain all of the traversal logic, while the rendering logic is contained in separate methods of the Handler. All I'm arguing is, that the graph traversal should be written as local as possible; best case, no node knows about anything but its immediate neighbors. But even that is not forced; a handler might contain more logic than just a single component, if necessary (an example of this in my post is the last UserHandler; it may shift more than one component, to consume the user-id and then continue routing). All I'm advocating for is that you somehow create a routing-graph in a logical manner and then make the decisions in the component that is responsible. > A large concept that this article also ignores is middleware. The > decorator pattern is quite a powerful one and is facilitated by nearly > every 3rd party mux implementation. Top level support for middleware makes > adding decorators to some, or all, endpoint rendering resources an easy > task regardless of the specific resource graph traversal required to > activate them. The ability to take a single purpose, well tested endpoint > and wrap it in other single purpose, well tested functionality (such as > logging, stats, tracing, retries, backoffs, circuit breaking, > authentication, etc.) without modifying the core logic of the endpoint is a > large value add. It's unclear how the "resource as a router" model could > easily provide such a feature. This is not to say it's impossible, I simply > haven't seen it done well outside the mux model before. > It is true that I largely ignore that. So far I've assumed that you likely want to have middleware near or at the top of the routing tree, so you'd end up wrapping your handler as a whole. There are ways to integrate middleware for subtrees, though. If you forego the advantage of easy static analysis (which you'd inherently have to, with middleware) you could use http.Handlers in the individual routing notes, instead of concrete types. Alternatively, you could add a `Middleware func(http.Handler) http.Handler` to your nodes, defaulting to a nop. These do require cooperation from the nodes (in that they need to provide the ability to hook things into subnodes), though. I find that realistic, given that it's one application, but if you heavily rely on third parties for individual nodes (think /debug/* handlers from the stdlib) this would be a problem. Depending on the complexity of the graph and your needs an easy solution is probably to just combine the two approaches; create a resource graph with concrete nodes and easy, statically deducible traversal for routing the request and wrap it with a mux, to inject middle-ware. As the mux only needs to do matching, not routing, it can be a lot simpler. I agree, that this needs some thinking. Personally, I don't rely heavily on middleware, much less deep in the routing graph, so this isn't a huge concern for me, personally. But it should get a better answer at some point :) > > On Sun, Jun 18, 2017 at 5:02 PM 'Axel Wagner' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > >> Hey gophers, >> >> in an attempt to rein in the HTTP router epidemic, I tried writing down >> a) why I think *any* router/muxer might not be a good thing to use (much >> less write) and b) what I consider good, practical advice on how to route >> requests instead. It's not rocket science or especially novel, but I wanted >> to provide more useful advice than just saying "just use net/http" and >> haven't seen that a lot previously. >> >> Feedback is welcome :) >> http://blog.merovius.de/2017/06/18/how-not-to-use-an-http-router.html >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
