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

181–190 of 236 posts

Re: Better HTTP server routing in Go 1.22

#181

Post by BodyCulture »

kunley wrote: post #76
oppositelock wrote: post #35

It's a nice change for little experimental programs, but production servers need lots of functionality that third party routers offer, like request middleware, better error handling, etc. It's tedious to build these on top of the native router, so convenience will steer people to excellent packages like Gin, Echo, Fiber, Gorilla, Chi, etc.

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!

Re: Better HTTP server routing in Go 1.22

#182

Post by drdaeman »

jupp0r wrote: post #179
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…

It's a programmer's error, so it should lead to a panic. There is simply no reason to ever handle this at runtime (as opposed to network errors or other things that can go wrong during normal operation and should be handled at runtime).

Not always, I can imagine a (weird, for sure) scenario where routes are a part of configuration, or are added dynamically at runtime.

There’s `recover` of course, but I see no harm in returning an `error`, especially given that `errors.Join` is a thing now, so one doesn’t need to copy-paste ifs.

The only reason not to is keeping the function signature intact.

Re: Better HTTP server routing in Go 1.22

#184

Post by the_gipsy »

badrequest wrote: post #168
the_gipsy wrote: post #78

Earlier quoted context omitted.

The zero-values idea, nil, reflection and stringly-typing all over stdlib and the most popular libs makes go not type safe. Were you thinking of statically typed?

I genuinely have no idea what you're referring to by "stringly-typing all over stdlib". I've written Go every day for the better part of a decade and used the standard library the whole time. What standard library functions require passing in the string of a type?

You are right, stdlib doesn't have much of stringly-typing.

However the core language way of dealing with enums for example is extremely weak. It's common to have a typed enum on a struct. When parsing the struct, random string (or whatever the alias is) values sneak in and the only thing you can do is validate.

Re: Better HTTP server routing in Go 1.22

#185

Post by Groxx »

silasdavis wrote: post #140
earthboundkid wrote: post #121

Earlier quoted context omitted.

Go's flag, log, image, and sql packages all work this way, so it's not just the HTTP router. I sort of see both sides. Having implicit registration makes it very easy to have different teams working on different packages and you just import the package and it registers itself. But it also makes the behavior of the resulting final binary hard to understand and based on implicit code instead of explicit. I personally t…

It doesn't feel to me like much of a gain over having said team expose a specific default self registration function. Then that act can be explicit rather than action at a distance on some dependency defined global state. I think this pattern in the standard library is a mistake.

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.

Re: Better HTTP server routing in Go 1.22

#186

Post by dimgl »

shortrounddev2 wrote: post #86
dimgl wrote: post #82

Earlier quoted context omitted.

You're joking, right? How is the second example better in any way? You're also doing more in your second example. You can still do service injection in JavaScript.

The 2nd example: 1. Uses declarative routing, which looks better and makes more sense than running a function to handle routing (e.g, you read it as "There is a handler named GetFoo living within the Foo controller that exists at the base route"). Declaration is more important to the end user than implementation when creating an interface. It also allows you to export these classes to a different Main method which ca…

You're making these statements as if the example you're presenting is the only one of its kind that has these properties. It's simply not the case. You can use middleware in other frameworks just as well. You can do input validation in other frameworks just as well. You can also class-based route handler encapsulation in other languages just as well. And I'd argue it looks _significantly_ cleaner than whatever is going on in ASP.NET land.

I'd really encourage you to explore other languages. If you're one of those "JavaScript is bad" people, there's plenty of others: Go, Ruby, Python... I'm surprised to be seeing this kind of comment on Hacker News to be honest.

Re: Better HTTP server routing in Go 1.22

#187

Post by dimgl »

mbb70 wrote: post #120
shortrounddev2 wrote: post #63

How did this kind of syntax become so popular? I think express is the first to do the scheme of: app.handleGet("/route/goes/here", (req, res) => { }); Which seems like it's useful for making really quick and dirty micro-services (nano-services, even), but I still vastly prefer the more declarative and modular schemes of bootstrap or asp.net: // Middleware automatically routes "/Foo" to FooController [Controller] publ…

Sinatra ( https://sinatrarb.com/ ) uses `get "/route/goes/here" do...` syntax and significantly predates express. I don't know of anything earlier, but I'm sure there are others.

Hilariously, C# used to have a framework named NancyFX which was inspired by Sinatra. The entire reason it existed was to get away from the ASP.NET MVC mess.

Thankfully it looks like even ASP.NET Core is no longer using this kind of syntax. https://learn.microsoft.com/en-us/aspnet/core/fundamentals/r...

Re: Better HTTP server routing in Go 1.22

#188

Post by eliben »

hknmtt wrote: post #152

> Therefore, the new ServeMux documentation meticulously describes the precedence rules for patterns This is so backwards it's not even funny. It is supposed to be exactly the other way - conrete paths MUST TAKE PRECEDENCE over patterns.

> conrete paths MUST TAKE PRECEDENCE over patterns.

And indeed they do.

Re: Better HTTP server routing in Go 1.22

#189

Post by drdaeman »

badrequest wrote: post #168
the_gipsy wrote: post #78

Earlier quoted context omitted.

The zero-values idea, nil, reflection and stringly-typing all over stdlib and the most popular libs makes go not type safe. Were you thinking of statically typed?

I genuinely have no idea what you're referring to by "stringly-typing all over stdlib". I've written Go every day for the better part of a decade and used the standard library the whole time. What standard library functions require passing in the string of a type?

Struct tags is the most notorious example.

They’re convenient but error-prone. I think everyone who wrote a decent amount of Go had that malformed, misspelled, or misnamed (“db” vs “sql”) tag at some point.

Re: Better HTTP server routing in Go 1.22

#190

Post by eliben »

rollulus wrote: post #42

Slightly off-topic: where does one get an overview of what is planned to go into a new release?

Changes are sometimes added to the release notes doc (in the master branch) during the dev cycle, but your best bet is watching the commit stream. The release notes are much more shaped up by the time RC rolls around (see https://github.com/golang/go/wiki/Go-Release-Cycle)
Post reply on HN