On Tue, Dec 19, 2017 at 4:52 AM, 'Kean Ho Chew' via golang-nuts < golang-nuts@googlegroups.com> wrote:
> >> 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. > "I am right, so you are just going to have to agree with me at some point" is not a very healthy base for discourse. > 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.) > This whole section is ultimately circular: "Routers are good, because Routers are good". You are arguing a) if you write your own Router, it will grow in features until it ultimately competes with other Routers. Yes, literally the point of the article. b) Routers implement a whole bunch of complicated code, to provide a DSL for routing (that "dynamic parameter thing" you are talking about) - literally the point of the article. c) It's a simple feature - but it's *not*. It's a super-duper-complicated feature (as evidenced by how much trouble it was to implement it j*ust for your own, application-specific usecase*) to replace something completely simple, which is something to the effect of userid := ShiftPath(req) (or whatever you want to use that for) at the correct spot of your code. The whole premise of this section is that you'd need to have a central, programmable component that takes as input a URL and as output some sort of representation of all its routing decisions (in the form of parameters and the like) and as output a specific location to jump through - which will then have to introspect this representation of routing decisions and reverse-engineer them, to figure out the pieces it needs. I'm arguing, that you should instead just *get rid* of that component, do the routing piece-by-piece, with golden variety control flow structures. You use the pieces of the URL you are making your decision on (the "dynamic parameters" you are talking about) at the place where you are extracting them instead of separating them out and trying to find a generic representation. And you end up with less total code, a comparable amount of self-written code and, most importantly, completely easy to read code. Because it's just regular control flow, like in any other Go program too. Try to, at least for the sake of argument, get rid of the premise that there needs to be a central, programmable component - a router. 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. > I posit, that my code is far more reusable than any code relying on any muxer out there. Having Handlers do their own routing is a prerequisite of re-using them elsewhere. By coupling them to a muxer, you are walling yourself off from people who don't use one or use a different one. For example, a common complaint from people is, that a bunch of stdlib-packages will register themselves on http.DefaultServeMux under /debug. This is an incarnation of *exactly* that problem: These packages where written under the assumption that there has to be a central routing component that dispatches all URLs, so they decide, for themselves, that they want to be under, e.g. <domain>/debug/pprof/heap. Which is not scalable (as it creates the risk of collisions), not reusable, not well-isolated. Contrast that with a world where they just provide an http.Handler that just assumes it's handling / and then does the routing below that itself. As a user of that library, you decide whether you want to handle it on /debug/pprof/heap, on /heapz or on /_/admin/heapdump. You strip whatever prefix you chose before dispatching to pprof.Handler and it does all the routing it needs for itself. Much more scalable (no collisions anymore, as you can just change the URL in case of a collision), much more reusable, much better isolated (suddenly, the user actually knows what URLs go where, instead of magically getting URLs registered). You should at least try to *consider* that having your routing logic in a single value might not be a good idea. Yes, there certainly could be things we can do to make it easier to do the routing in-Handler (for example, we could probably use an API to determine absolute URLs to link to, from a handler), but writing fifteen hundred DSLs to express something Go already can express *just as well *is not the solution. 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. > 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. > -- 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.
