*The basic arguments, again, are a) Having a Router doesn't actually save you code in a significant way, because you are replacing a conditional with a function call and b) instead you are pulling a whole lot of unnecessary code into your program, that implements a DSL to express the routing control-flow; but which is less powerful than the Go code it replaces. The argument isn't "write your own Router vs. use an existing one", it's "not have a Router vs. write your own", because it seems the latter is, where the idea of Routers has lead us.*
My bad, we should focus on "not having a router vs write your own". Keep in mind that I'm only pointing out the resilience of the standard library team developing your "ShiftPath" or my "parse_url" is the primary cause of why people charging towards writing a new routers. In my next refactoring, it is either I roll out the a new parser library or a new router. The latter makes more sense since it simplifies the code. Just look at the httprouter source code example (https://astaxie.gitbooks.io/build-web-application-with-golang/de/08.3.html) vs my creation (https://gitlab.com/holloway/golang-web-tutorial/blob/master/sockets/rest/standard/standard.go). Personally, in large scale project, I prefer the former due to cleaner code. So that 2 months later when I returned from another large scale project, I can easily relearn what I did. The latter requires new considerations: 1. I need educate every single developer in the project about the structure I'm using (MVC? no. Looks like MVVM? maybe, let's call it MVVMVC?.). 2. It's so easy to have inexperienced player to screw things up because it's something new. 3. Pray that I'm not encouraging some hot-headed developers rolling out their own in the company. It boils down to: 1. Is it worth the cost for sticking to standard libraries by creating an entire architecture and roll out a new set of educations? Learning: As I said earlier: striking the balance - just as others said: hybrid. Not all self-written artwork is good, neither abandoning the collaborative efforts help either. Objective of the development should be given as priority one. If I'm given a 1 day deadline, I'll still use Gorilla/mux router (skip the reeducation). If I don't face any time constraint, I will use my refactored parse_url / your shiftPath method as I clearly can see the performance by just following the flows (unlike the mux). If we're going to be religious about "doing one thing right", which is using standard library, as least, don't leave your tail for others to pull. This whole standard library is clearly missing something for the web development crew, something crucial yet simple: such as the parser feature both of us are looking for. You do not need to use regex for the DSL parameters like Gorilla/mux did because that introduce double validations instead. Yet, you still need to work with pattern such as: */Articles/{aid}/Comments/{cid}/likes*, which AFAIK, httprouter can't handle (correct me if I'm wrong; one of my research point leads to here: https://husobee.github.io/golang/url-router/2015/06/15/why-do-all-golang-url-routers-suck.html ). p/s: I'm amazed by people bringing {id [0-9]+} regex validation into DSL parameter to complicate simple things. Eisenstein was right: simple is good, not simpler. Regards, Kean -- 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.
