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

221–230 of 236 posts

Re: Better HTTP server routing in Go 1.22

#221

Post by Groxx »

cowl wrote: post #217
Groxx wrote: post #185

Earlier quoted context omitted.

Yeah, the trade-off is literally: import _ "thing" Vs: import "thing" thing.Register() But one uses a strange construct to save a single line, loses the ability to control order, and encourages people to use globals that they can't control.

thing.Register() may register a route that conflicts with yours and it will never be matched in this case if declaration order was taken into account. You may discover this too late when you either have missed important calls on that thing or when requests intended for that thing are causing unintended effects on your first declared route.

That is all also true when doing the same thing in an init func.

Re: Better HTTP server routing in Go 1.22

#222

Post by [deleted] »

flakes wrote: post #218
Groxx wrote: post #185

Earlier quoted context omitted.

Yeah, the trade-off is literally: import _ "thing" Vs: import "thing" thing.Register() But one uses a strange construct to save a single line, loses the ability to control order, and encourages people to use globals that they can't control.

I very much dislike import side effects in any language. Im a lot happier where thing.Register() is still forced to happen in the main function. Still, I can understand it for some components like loggers to not add boiler plate to every library. However, I was very uneasy to see that enabling gzip decompression in a gRPC server is done through a magic _ import. You have to initialize the server anyways, so why not j…

[deleted]

Re: Better HTTP server routing in Go 1.22

#223

Post by Cupprum »

arp242 wrote: post #193
Cupprum wrote: post #143

Earlier quoted context omitted.

How much time do you spend working on fsnotify if i may ask.

I spent quite a bit of time on it last year, a few weeks of full-time work or so, but haven't spent anything on it for quite a while. There's a bunch of things I'd like to do so I'll probably spend another burst of effort in the future. It's kind of an annoying project to work on because everything is platform-dependent (and at times fickle) so you can't "just" run "go test ./..." but really do need to test it on all…

Have you tried executing the tests in github actions where the tests would run on different Operating Systems?

Re: Better HTTP server routing in Go 1.22

#224

Post by farhaven »

tptacek wrote: post #129
bananapub wrote: post #124

Earlier quoted context omitted.

Go as a language is generally not sophisticated enough to do that sort of thing. A counter- and/or example of this is what Service Weaver does to try to bomb builds when generated files are older than their dependencies.

I'm having trouble thinking of a mainstream production language with a stronger type system that could make a compile error out of the string argument passed to an HTTP router; can you think of one? Or of a non-string-typing for routes that solves the same problem, again in something people ordinarily use to deploy to production?

OCaml can definitely do it (for example, you get a compiler error if you pass the wrong arguments to a `printf` where the format string specifies, say a number, but you pass in a string).

Rust can very likely do it by leveraging their `build.rs` stuff to parse and validate call sites of the registration and parameters.

Zig can probably do it with their comptime stuff.

In theory, Go could do the same (but that would mean special-casing the `net/http` handler registration in the compiler). At least `go vet` is smart enough to yell at you about wrong format string arguments.

Re: Better HTTP server routing in Go 1.22

#225

Post by kunley »

BodyCulture wrote: post #181
kunley wrote: post #76

Earlier quoted context omitted.

Honestly, there is a lot of praise of the middleware in these projects, but I recently found out that most of them are unable to handle parsing the Accept and Accept-Encoding header properly, that is: according to the RFC, with weights. This means that the general perception "these projects are production-quality but stdlib isn't" is misleading. If I have to choose web framework or library that implements feature X i…

Please post issue numbers, thanks!

Excuse me, what issue numbers?

Re: Better HTTP server routing in Go 1.22

#226

Post by thiht »

cowl wrote: post #211
thiht wrote: post #109

Earlier quoted context omitted.

That was my gut feeling as well, but honestly when using Gin, having methods like .Get(), .Post() etc. has never solved anything for me. Having a single registration method with the method in the string is probably 100% fine.

"probably" is key Here. this introduces the possibility of typo erros that can even be discovered late. Now you will need a Vet check to make sure that GET, POST etc are written correctly instead of letting the compiler to do it's job. .Get(), Post() get compiler guarantees that they are sending the right Method string.

I agree on principle, but in practice routers rely on arbitrary strings anyway. I don't see why the verb is not just a part of the route.

In my head it's as if we did this:

    http.Segments("foo", "bar", http.Param("barID"), "baz")
instead of:

    /foo/bar/:barID/baz
Is it sliiiightly safer? Yes. Is it insane? Also yes.

Re: Better HTTP server routing in Go 1.22

#227

Post by imetatroll »

kjksf wrote: post #49
imetatroll wrote: post #37

Earlier quoted context omitted.

Just add a new method with a new name. Vastly better than the proposal at hand.

Is it vastly better, though? With this proposal if you already have an app using mux, you can change one line and you have app using new mux which you can then evolve to take advantage of additional capabilities. With new name you have to rename all your codebase. Not to mention that writing a wrapper with an API to your liking is few trivial lines of code so this is bike shedding at its finest.

I shouldn't have to wrap a poor design choice.

Re: Better HTTP server routing in Go 1.22

#228

Post by bborud »

I would actually have preferred that the old mux was left as is, and that the new mux had been a new package. This would have eliminated the need to be backwards compatible and allowed more freedom in creating a better API. I think that putting the method in the matching expression is a step back as it can't make use of the compiler to enforce correctness.

Re: Better HTTP server routing in Go 1.22

#229

Post by greatgib »

imetatroll wrote: post #36

Man I really really dislike this proposal. Putting the http request method into the URI... an just sometimes... oh and maybe do "POST,PUT,PATCH /something". Just no thank you. Make a dedicated method that accepts http request method names if you must do something.

I agree, does not make much sense to design it like that. The function could have another argument for listing methods or options.

Re: Better HTTP server routing in Go 1.22

#230

Post by arp242 »

Cupprum wrote: post #223
arp242 wrote: post #193

Earlier quoted context omitted.

I spent quite a bit of time on it last year, a few weeks of full-time work or so, but haven't spent anything on it for quite a while. There's a bunch of things I'd like to do so I'll probably spend another burst of effort in the future. It's kind of an annoying project to work on because everything is platform-dependent (and at times fickle) so you can't "just" run "go test ./..." but really do need to test it on all…

Have you tried executing the tests in github actions where the tests would run on different Operating Systems?

There's an extensive CI setup, but it takes forever to run. And even if it was fast, it would still be a frustratingly slow feedback loop while developing.
Post reply on HN