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

151–160 of 236 posts

Re: Better HTTP server routing in Go 1.22

#151

Post by d-z-m »

avianlyric wrote: post #144
Macha wrote: post #131

Earlier quoted context omitted.

How is "this api usage was allowed before and now panics" not a breaking change?

Which specific API usage was allowed before and now panics? As far as I can see the only historically allowable API usage that would now panic, is registering exactly the same path twice, which in my books is just a bug. Certainly it's technically a breaking change, but there's huge difference between making all existing usage of the mux interface incompatible with the new changes, and only making obviously incorrect…

> As far as I can see the only historically allowable API usage that would now panic, is registering exactly the same path twice.

This has always resulted in a panic[0].

[0]: https://cs.opensource.google/go/go/+/refs/tags/go1.19:src/ne...

Re: Better HTTP server routing in Go 1.22

#152

Post by hknmtt »

> 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.

Re: Better HTTP server routing in Go 1.22

#153

Post by jiehong »

avianlyric wrote: post #8
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...

Isn’t that just a consequence of Go’s backwards compatibility guarantee? Adding new arguments to the Mux interface would break existing code, given the method signature can’t be changed, these magic strings seem like a reasonable compromise. It not like HTTP verbs are going to change anytime soon, and it’s trivial to validate them during register, or via static analysis. So I’m not sure what value the use of constant…

Isn’t function overloading based on the number of arguments a thing in go?

That wouldn’t break compatibility

Re: Better HTTP server routing in Go 1.22

#154

Post by bborud »

shortrounddev2 wrote: post #96
bborud wrote: post #93

Earlier quoted context omitted.

In order for code to be maintainable it first has to be readable. The second example has poor readability. And that's even before we get to the issue that this approach has fallen out of favor exactly because it result in code that can be a pain in the neck to figure out. Please don't do this. This is the kind of legacy approach that I try to teach people working for me NOT to follow.

> The second example has poor readability Only if you don't know C# or asp.net (or bootstrap). In which case: why would you be working for an organization which does? > And that's even before we get to the issue that this approach has fallen out of favor exactly because it result in code that can be a pain in the neck to figure out. This kind of structured approach has fallen out of favor because it's become more pop…

> is how you get hundreds of poorly written spaghetti code

So what you are saying is that the IoC / Decorator approach is the way to avoid spaghetti code? That's an interesting assertion.

> You are setting yourself up for some bad tech debt in the future

You mean like being saddled with a product that depends on a large framework that fewer and fewer people want to deal with?

The way to avoid tech debt is to retain plasticity, keep more options open and not paint yourself into a corner where your choice of framework dictates how you structure entire systems.

And, of course, to hire people based on talent and ability rather than a line on their CV that promises experience with a given framework.

Re: Better HTTP server routing in Go 1.22

#155

Post by hashworks »

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.

In the example there are no concrete path, both have variables. Is there an example in the documentation that allows paths with variables precedence over concrete paths?

Re: Better HTTP server routing in Go 1.22

#156

Post by shortrounddev2 »

bborud wrote: post #146
shortrounddev2 wrote: post #107

Earlier quoted context omitted.

> No, having to spend months learning how web frameworks are going to deal with that piece of code is not a good thing Are you in the habit of hiring people without experience? Developers had to spend months (years) learning javascript before they learned any frameworks. Would you rather switch to point and click programming so that your developers don't need to actually learn to code? > It means that the code is rea…

> Are you in the habit of hiring people without experience? I hire people who I believe can produce quality code as part of a team. I've hired people with zero experience and with 35+ years of experience. I've probably hired somewhere around 200 people. I have no idea how many people I've interviewed. I have both hired people with decades of experience who turned out to be poor hires, and I've hired people without an…

> For one it means you can never hire people who have newly graduated.

Not necessarily. I wouldn't hire a new grad without an internship or without even some personal project experience. If I were to hire someone out of college, I would expect them to have made a website at some point before and to be able to explain to me how it works. I would also expect them to be able to make the same website in different frameworks if asked to change their tech stack.

> I can understand that you are defensive if you have spent years making this investment and someone suggests you have made a poor choice. But I think it would be time well spent to try to understand why many companies are moving away from the "big framework" approach.

It's quite to opposite: I would expect anybody working with me to be flexible enough to learn different ways of expressing themselves in code, and I would expect them to not take several months to learn something as simple as a web framework.

Re: Better HTTP server routing in Go 1.22

#157

Post by greiskul »

danpalmer wrote: post #72
badrequest wrote: post #53

Earlier quoted context omitted.

What common use-cases does it not support?

The `/foo/bar` and `/foo/*` use-case, where you want the first to go to a special page and the latter to go to some regular page. Perhaps the former is hard-coded/static and the latter looks up some URL parameter in a database. You can of course always implement this within `/foo/*`, but then you're implementing your own URL routing and working around the framework rather than working inside the framework. This feels…

This work, the panic is only triggered when the precedence rules can't fix a conflict.

The behaviour documented here is actually extremely sensible and is best practices for anyone calling themselves a software engineer. Fail as early as possible, with as clear a message as possible.

Re: Better HTTP server routing in Go 1.22

#158

Post by avianlyric »

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…

> And that input validation is handled automatically. Named parameters exist on a lot of these frameworks as well, but Javascript doesn't provide static typing so it's not a good language for writing a backend in

God the number of bugs and bad practices I've had to deal with and work around do to auto-magic casting of url segments, or JSON blobs into language native types, is too damn high. Auto input validation based on function parameter types sounds good, until you think about for more than a couple of seconds and start to realise type primitives definitions vary significantly between languages. Using them for input validation just means exporting your languages type primitives into your API, with zero consideration of if that's a good idea.

The classic example of this is people using the `int` type for `id`s just because the IDs happen to contain only digits. Ignoring the fact that identifiers aren't numbers (performing numeric operations on them doesn't make any sense), but because you've now blindly exported the `int` type into your API, you also export nastiness like precision (try preserving leading zeros with your `int` type) and rollovers into your API. Two things that make zero sense when dealing with identifiers, and two things that often change depending on the exact platform your software is running on.

Re: Better HTTP server routing in Go 1.22

#159

Post by greiskul »

lucb1e wrote: post #130
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 would have expected the last one to override the first when registering routes. That seems to be the behavior I see most (not specific to web servers). Given opposite expectations, erroring out makes sense, but a panic? Does that mean it crashes the whole web server when a client first accesses it, when you launch the server, or does it return a 500 to the client?

When you launch the server. Idea is that you want to catch errors as early as possible in the development process, and by crashing the server, the programmer that wrote it will catch it.

Re: Better HTTP server routing in Go 1.22

#160

Post by msmith »

troupo wrote: post #118
numbsafari wrote: post #116

Earlier quoted context omitted.

It’s not an exception. There is no magic. Large code bases are large, and not every program is your simple crud app with a handful of endpoints that can be meaningfully managed a single function.

Hard panic in a "not simple app with large codebase" app because you couldn't match a route is amateur hour.

I think you're assuming that the panic happens when a request is received, but it actually happens when a conflicting route is registered.

To me, that's reasonable behavior and is consistent with other things such as https://pkg.go.dev/regexp#MustCompile

Post reply on HN