> > > I disagree. I am making the argument that the concept of a router is > inherently broken. Writing your own router doesn't improve on that. Don't > write a router, write routing logic. > > At some point you might have to agree with me. By abstracting the routing logic into a library to 'go get' in the future, it will become a new one like Gorilla/mux. Example, it took me a while to write the dynamic parameter that I'm looking for (https://gitlab.com/holloway/golang-web-tutorial/blob/master/sockets/rest/standard/standard.go#L27). This is rather a simple feature. If the request is being overlook since the beginning, I don't think the router epidemic will come out at the first place. (Unless, I'm not aware that Go is on a mission to simplify the web url, like taking the dynamic url out the game.)
Due to my personal learning requirement sticking to the standard library, I ended up exploiting the handleFunc "/" instead, which yielded a different code pattern for server side; far from any guides that I learnt, neither the boilerplate in the post. Or, if you prefer: Instead of writing a domain specific language (in the > form of a single router type) for routing which is general enough to cover > any and all usecases, just use the existing language to express the logic. > As the graph of routes is the same and needs to be written down either way, > you end up with effectively the same amount of code, but it is more > readable, more understandable, more localized and overall clearer. IMHO. > It's really depends on the objectives. Yes, I agree with you that writing codes that fosters linear reading instead of hopping around libraries greatly helps in debugging but it also contributes a whole new level of scaling problem (reusability). Keep in mind that the goal of creating library is to ensure re-usability that leads to battle-tested codes. It's a matter of striking the balance between those 2 constraints. p/s: I'm a new comer (transition from C and Python) to Go but due to the >> fact that I need just a simple dynamic parameter url feature >> > > The post specifically mentions how to do this. > > You don't *have* to heed my advice, of course. Feel free to use > gorilla/mux or any other router, if you prefer. I just wanted to give the > people who *want* to know how to get by with the stdlib the tools > necessary to do so :) > Well, I took both paths but I prefer my own parser ;-). There are still some works to do with the new pattern but that comes after when I learn how to create a library and start splitting the 1 page source codes into a manageable format. Keep up the education though. You did a good job. p/s: The sole reason I voiced out, mainly because I don't want such a wonderful, artistic and masterpiece language heading towards the Python2 vs. Python3 war direction. This language is majestic and beautifully crafted for modern computing that one who been through the pain from Java, both Pythons, C, Embedded C and Ruby on Rails can really appreciate its beauty. Peace, 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.
