I also think its a bit of a false dichotomy; I use a hybrid approach, where I have a server's public interface be a http.Handler, but its internal implementation of ServeHTTP uses a router to dispatch to several methods on the server.
https://play.golang.org/p/-W4tHmiUve is a stripped down example from a real server I wrote at some point. I think this is nicely layered; you can have different components of your server use completely different routing logic if you want (say for portions of the server contributed by different people/teams; the pprof endpoints would be an example of this), and then its all just registered in main() generally using good old http.ServeMux for hostname-routing (perhaps getting the hostname itself from a flag). Sanjay On Tuesday, December 19, 2017 at 1:14:18 AM UTC-8, rog wrote: > > > You strip whatever prefix you chose before dispatching to pprof.Handler > and it does all the routing it needs for itself. > > It would be great if that was actually a viable approach in general, > but unfortunately it's not, because it's not uncommon to need to know > the absolute path that's being served, which is lost when using this > technique. One example is when you need to form a relative URL to > another part of the name space (you know absolute path of the > destination, but you can only create a relative URL path if you know > the absolute path being served too). > > > a) Having a Router doesn't actually save you code in a significant way, > because you are replacing a conditional with a function call > > It might not save *much* code, but it's generally just boilerplate, > and every conditional is another condition that can be wrong. > > > b) instead you are pulling a whole lot of unnecessary code into your > program, that implements a DSL to express the routing control-flow > > Sure, there's an argument to remove *any* external dependency - there > are costs and benefits here, and they need to be evaluated for every > project. > > Personally, I think there's room for a hybrid approach - routers, > particularly structured routers such as > github.com/julienschmidt/httprouter, can make the code more obvious, > maintainable (and probably faster too), but there's nothing stopping > you from combining that kind of routing with custom routing code for > some sub-paths. > > Using a router DSL can have other advantages. If you express things > that way, the routes become amenable to programmatic analysis. We're > using that to automatically generate API client code, for example. > -- 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.
