On Sat, Jun 24, 2017 at 11:43 AM, <prades.m...@gmail.com> wrote: > The goal of a (proper) router is to decouple routes from handlers, thus > making refactoring easier by adopting a declarative form rather than an > imperative one. >
Yes. And it is my opinion that this is a bad thing. > It's the good old builder pattern. By deeming it unnecessary you did > nothing but couple your handlers with your routes. That's the only thing > you did. You didn't make your code easier to read, you cluttered it with > unnecessary imperative logic that could be simply abstracted while > remaining no less readable if not more. > >> I think I also showed pretty clearly, that there is no actual difference in the level of abstraction. You can, if you want, create a 1:1 correspondence of LOC; the difference just being, where they are. TBH, I rather think that the abstraction is cleaner if the handler does its own routing. That way I can simply take it and plug it into a different web-app at any path I like. Say my RPC library provides an HTTP interface for debugging. It has a couple of pages with html-forms, that you can input your requests and see the resulting responses, and the like. What I'm proposing is, that this handler makes the promise to handle `/` and do the routing for all those forms and subpages (including static assets) relative to that. That way I can then, in my app, put it behind an authenticated `/debug` sub-path, just by adding an if-statement. Think about how the muxer-pattern would do that. Would I need to manually set up a bunch of routes? And if they changed, would everyone who imports that handler need to change their routes? Would the constructor take a muxer to set up it's own routes? If so, which muxer and would libraries now have a dependency for your app to use a specific muxer? What you'd probably end up with as the best solution is for the constructor of that handler to set up its own muxer, wire up the routes and then call into that in ServeHTTP. And because it can't know where the user wants the http-endpoint end up in the final app, do it relative to / (or, alternatively, take a prefix. The difference doesn't really matter for my point). But that's pretty much *exactly*, what I suggest already. So yes, the difference comes exactly down to what you say; whether you use an imperative, Turing complete language to make the routing decisions. Or whether you take a "declarative" DSL, embed it into go and hope it's powerful enough to express all the routes you want to take. And I think, there is a strong argument to be made that the abundance of existing routers shows that there *isn't* any one implementation of such a DSL powerful enough to fulfill everyone's needs. That this nice abstraction that you are talking about just doesn't exist and will always be leaky. It is also my *opinion* (but this comes down to taste), that imperative code is easier to read and always easier to debug and reason about (that is pretty much the reason I love go; source code maps very closely to computation). But even if you disagree about that, you can *still* write exactly the same kind of declarative code that you are talking about; just doing it in your Handler, instead of as methods on a muxer. Just add a couple of helpers like AcceptMethods(res http.ResponseWriter, req *http.Request, methods ...string) AcceptPathPrefix(res http.ResponseWriter, req *http.Request, prefix string) AcceptContentTypes(res http.ResponseWriter, req *http.Request, contentTypes ...string) > Your solution certainly doesn't get more readable as the amount of routes > in an app gets larger. > We just have to agree to disagree on this one :) > > > Le lundi 19 juin 2017 00:02:37 UTC+2, Axel Wagner a écrit : >> >> Hey gophers, >> >> in an attempt to rein in the HTTP router epidemic, I tried writing down >> a) why I think *any* router/muxer might not be a good thing to use (much >> less write) and b) what I consider good, practical advice on how to route >> requests instead. It's not rocket science or especially novel, but I wanted >> to provide more useful advice than just saying "just use net/http" and >> haven't seen that a lot previously. >> >> Feedback is welcome :) >> http://blog.merovius.de/2017/06/18/how-not-to-use-an-http-router.html >> > -- > 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.
