> 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.
