Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Better HTTP server routing in Go 1.22

eli.thegreenplace.net

Post reply on HN
Print view View original

21–30 of 236 posts

Re: Better HTTP server routing in Go 1.22

#21

Post by karmakaze »

eknkc wrote: post #10
fideloper wrote: post #5

Forcing a panic when 2 routes are matched seems counter intuitive to me (versus, idk, every other web framework which uses the first-to-be-registered route that matches). Are there go-specific reasons for that? The edge case of "you might register HTTP routes in a bunch of places and it's harder to find that if multiple routes match" seems like something that be worked around with tooling. I've (ab)used the behavior…

I believe it allows `/foo/bar` and `/foo/{id}` as the first one is more specific and has precedence. This looks fine to me. Looks like it will panic in case you have `/foo/{id}/delete` and `/foo/bar/{action}`. /foo/bar/delete will match both, none is more specific so it panics. Feels reasonable. Having a first one wins precedence might be better though.

I would expect and prefer the longer literal prefix to match. If the goal is to not have so many different routers in use, having some options like this case would be better than having one opinionated Go-way, which is how we end up with many libraries to fill common gaps.

Re: Better HTTP server routing in Go 1.22

#22

Post by Cupprum »

The gorrila/mux project is weird and I am confused by it. Last year the maintainers archived the gorrila/mux project. Therefore i switched to another multiplexor called gin-gonic. Now as i saw the OP mentioning it in their blog, i went to take a look at the gorrila/mux project again to verify i correctly remembered the project to be archived. Apparently its not archived anymore, which brings the stability of the whole project to the question, or maybe it proves that Open Source is actually very stable. That if a project is missing developers, some other people can step up and start maintaining the solution.

But its nice that this functionality will be provided by Golang itself.

Re: Better HTTP server routing in Go 1.22

#23

Post by candiddevmike »

gempir wrote: post #3

As I commented[1] I think the syntax is flawed in the proposal. You need to weirdly create a magic string to define your handler. Why not make it an actual argument, then using already existing constants is easier. [1] https://github.com/golang/go/issues/61410#issuecomment-16580...

What's wrong with automatically registering a HEAD route?

Re: Better HTTP server routing in Go 1.22

#24

Post by figmert »

Cupprum wrote: post #22

The gorrila/mux project is weird and I am confused by it. Last year the maintainers archived the gorrila/mux project. Therefore i switched to another multiplexor called gin-gonic. Now as i saw the OP mentioning it in their blog, i went to take a look at the gorrila/mux project again to verify i correctly remembered the project to be archived. Apparently its not archived anymore, which brings the stability of the whol…

The ownership transfer was publicly announced in quite a few places. Most notably gorilla's blog[0], but also on Reddit[1] as well as HN[2], though it didn't get much reaction on HN.

[0] https://gorilla.github.io/blog/2023-07-17-project-status-upd...

[1] https://www.reddit.com/r/golang/comments/1528e25/gorilla_web...

[2] https://news.ycombinator.com/item?id=36935541

Re: Better HTTP server routing in Go 1.22

#25

Post by icholy »

c7DJTLrn wrote: post #19
jamescun wrote: post #18

I don't like this. Is there a reason for using a stringified method prefix? I'd prefer the type safety of verb-specific methods (i.e. mux.Get, mux.Post etc) than magic strings validated at run time. Additionally editors can autocomplete/intellisense methods.

Not a fan either. I want to be sure that routing is going to work at compile time, not at runtime.

If this turns out to be real issue (which I seriously doubt), then they'll add a vet check.

Re: Better HTTP server routing in Go 1.22

#26

Post by Loic »

creshal wrote: post #2

Will this finally end the eternal golang http router bikeshedding?

No because we don't have named routes and the ability to reverse build the URL like in the Django router. So, at lest this functionality will be again built on top with different opinions on the best way to do it.

Re: Better HTTP server routing in Go 1.22

#27

Post by shp0ngle »

One thing I don't like about default ServeMux is that addresses are prefixes.

So `mux.HandleFunc("/"...)` always handles _everything_.

And there is no easy way to say "no, just handle exact matches, plus maybe ? queries". As gorilla/mux does.

I don't think that is changed in the new go?

Re: Better HTTP server routing in Go 1.22

#29

Post by jerf »

kandros wrote: post #4
creshal wrote: post #2

Will this finally end the eternal golang http router bikeshedding?

lol no, will start the proliferation of more different abstractions over it

Not likely. Routers are so easy to write that the "different abstractions" have already been written, and are unaffected by this change to the standard library, because they don't build on the standard library, they plug in next to it.

The primary utility of Go's net/http is that it is a "minimal framework" that provides a fairly common plug-level compatibility between various bits and pieces. The particular bits that it happens to provide by "default" are not really that consequential by comparison. I was actually surprised anyone touched the standard mux at all at this late date because there's so many other options already, and most of them just plug in with no fuss at all. All a router is is a handler that examines the request and then calls another handler as a result.

Post reply on HN