>
> 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.h
*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
I also think its a bit of a false dichotomy; I use a hybrid approach, where
I have a server's public interface be a http.Handler, but its internal
implementation of ServeHTTP uses a router to dispatch to several methods on
the server.
https://play.golang.org/p/-W4tHmiUve is a stripped down exam
> 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 se
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.
>>
>
>
>
> 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
On Mon, Dec 18, 2017 at 5:50 AM, 'Kean Ho Chew' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> IMO, this article itself is indeed indicating there is an important
> feature not fulfilled by the standard package. It is asking people to write
> their own routers indirectly
>
I disagree. I
IMO, this article itself is indeed indicating there is an important feature
not fulfilled by the standard package. It is asking people to write their
own routers indirectly, thus, leading to the current situation (e.g: more
routers). There is a much better guide
here:
https://stackoverflow.com
On Sat, Jun 24, 2017 at 11:43 AM, 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 patte
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. 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
Yeah, I do. And that's what I get for not testing my code, this is the
second mistake someone found :) Thanks for noticing it, I'll push a fix in
a minute.
On Sat, Jun 24, 2017 at 2:54 AM, Steve Roth wrote:
> Hello, Axel,
>
> I like your concept and I am applying it. But I believe that the code
Hello, Axel,
I like your concept and I am applying it. But I believe that the code in
your blog post is broken. In various places you call
head, r.URL.String = SplitPath(r.URL.String)
But r.URL.String is a function, not a property. This code doesn't compile.
I think perhaps maybe you meant
I am not sure, but i think you may find this
interesting https://github.com/mrwnmonm/handler
On Monday, June 19, 2017 at 12:02:37 AM UTC+2, Axel Wagner wrote:
>
> Hey gophers,
>
> in an attempt to rein in the HTTP router epidemic, I tried writing down a)
> why I think *any* router/muxer might n
Hey,
On Mon, Jun 19, 2017 at 12:43 PM, wrote:
> I don t feel like expanding code helps to better explain
> the how/what/why of a sudden 42 question ? (why this /whatever/ has
> failed, I believe it should not)
>
I may be biased in this regard by personal experience. I am running (as an
ops-pers
hi,
I understand what / why you came to that given your explanation,
but I disagrees a lot to it.
I don t feel like expanding code helps to better explain
the how/what/why of a sudden 42 question ? (why this /whatever/ has failed,
I believe it should not)
I m pretty sure its a good way to mult
Hi Axel
I agree on the suggestions you give on the article, even I have another
view of the "epidemic".
To be short: almost none of the "Basic/Simple/lightweight http
rest/mux/routers/socallframeworks" is supposed to have a real usage.
Sometimes I have the task (I'm the lucky guy) to do techni
On Monday, 19 June 2017 01:02:37 UTC+3, Axel Wagner wrote:
>
> 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
17 matches
Mail list logo
