Great syntax. I didn't use any third-party routers, because implementing my own router is not a big deal, but this is just great.
It is a big deal if you want to have RESTful routing.
Better HTTP server routing in Go 1.22
101–110 of 236 posts
Re: Better HTTP server routing in Go 1.22
#102As 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…
Surely the changes to panic on conflicting routes being discussed upstream already prove they're willing to flex on that guarantee?
Re: Better HTTP server routing in Go 1.22
#103Earlier quoted context omitted.
Your complaint is that you have to understand your web framework before writing a program in it? Is that not the case with ALL web frameworks? > And you're now also stuck with vendor lockin to whatever framework/compiler was using them I don't understand. If you choose a web framework, you are locked in to developing things in that framework from now on. In what world do companies try to change web frameworks without…
>Your complaint is that you have to understand your web framework before writing a program in it? Is that not the case with ALL web frameworks? My complaint is that I don't want things in my code affecting my code that aren't code . Most web frameworks avoid this, while the more enterprise stuff like Spring, Dotnet, et. al seem to lean into it. It's kind of the same argument as SQL stored procs. Should you rely on em…
> Most web frameworks avoid this
I don't know if that's true, but I doubt it.
> My complaint is that I don't want things in my code affecting my code that aren't code
Many things affect your code under the hood that you don't see. There is no difference between using a decorator/attribute and having a config.json file for other things.
> while the more enterprise stuff like Spring, Dotnet, et. al seem to lean into it.
Because they are responsible for larger services which need to be more maintainable and stable.
> But if I can't compile something in my head at a glance, it shouldn't be a part of the codebase IMO.
This would preclude ever using a programming language or framework which you don't already know. You have been taught to write web services in one particular way; the fact that you don't know other ways doesn't make them "unreadable", it just means you don't know how to read it
Re: Better HTTP server routing in Go 1.22
#104Earlier 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…
> 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?
You've never taken a job working in a language you don't know yet? Anecdotally this is a common thing. In fact, my most recent job hired me to write C# with nothing but prior Go/Python experience.
> This kind of structured approach has fallen out of favor because it's become more popular to hire javascript and react developers straight out of boot camp who have only been taught how to code one or two things.
This comes across to me as needlessly bitter to folks with less experience than you.
Re: Better HTTP server routing in Go 1.22
#105It seems like a very bizarre design choice, especially by an official language team, to use prefix strings instead of an enum. For example: (Http.GET, "/path") Rather than the current: ("GET /path") Odd.
This is a case where I, as a Go developer, would prefer to have function overloading for the sake of backwards compatibility . Because the compatibility promise is great, but the quirks caused by it aren't.
Re: Better HTTP server routing in Go 1.22
#106How 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…
Controller style declaration is often an overkill, it's also not exactly friendly to AOT. I personally prefer using MinApi style of declaration (first example). It can do request validation, model binding and inject services too:
app.MapGet("/", async (
[FromBody] User user,
[FromServices] MyService service) =>
{
await service.Handle(user);
return Results.Ok();
});Re: Better HTTP server routing in Go 1.22
#107Earlier quoted context omitted.
Your complaint is that you have to understand your web framework before writing a program in it? Is that not the case with ALL web frameworks? > And you're now also stuck with vendor lockin to whatever framework/compiler was using them I don't understand. If you choose a web framework, you are locked in to developing things in that framework from now on. In what world do companies try to change web frameworks without…
No, having to spend months learning how web frameworks are going to deal with that piece of code is not a good thing. It means that the code is readable only to those who have spent a lot of time working with that framework. And it is one thing to be able to guess what is going on, if you are only superficially familiar with the framework. It is another thing entirely to know enough to be able to debug the code or to…
> 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 readable only to those who have spent a lot of time working with that framework
Knowing the framework (or being able to learn) that the business is based on should be a requirement for working there. You should not hire people who are incapable of learning things, or who can only do things in one particular way
> And he does have a point about vendor lock-in. I tend to classify these kinds of frameworks as "cancerous" - as they metastasize and define how you can express yourself, and paint you into a corner where it gets really hard to rid your codebase of the framework should that be necessary.
All frameworks will place limitations on how you express yourself. Compared to javascript, C# (and .net) offer far more flexibility and metaprogramming abilities. Try declaratively validating user input in Javascript or Typescript without having to rely on some kind of runtime hack or re-writing the same code over and over.
If you were to decide to ditch express and move to a different framework, then the way you have written your express handlers would also have to be totally discarded. By choosing any language or framework, you are tying yourself to the technology decision and labor pool associated
> Part of my job in the past has to be technical due dil for M&A. This kind of design approach usually results in a red flag if a major part of the valuation is the codebase.
I question your judgment if using a well documented and not at all obscure framework based on some of the most popular frameworks out there (MVC style, bootstrap, etc.) raises a red flag. It would indicate, to me, your lack of experience in writing or reading code rather than anything about the framework itself. If having a javascript backend isn't a red flag in itself to you, then I would pretty much just discard any feedback you would have about a web backend
Re: Better HTTP server routing in Go 1.22
#108Forcing 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.
Na it’s dumb. Bar is very specific. It should be picked.
Re: Better HTTP server routing in Go 1.22
#109As 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...
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.
Re: Better HTTP server routing in Go 1.22
#110Earlier 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…
This is straight up wrong. Documentation can be generated from either pattern. It can also do authorization if you wish so (middlewares, attributes, you can do it however you want). We get it, you like the controller pattern, but please do not post incorrect information to prove the point.