Why The Golang 1.22 HTTP Router Is Not Great

SUBSCRIBE OR NO MARGARITAS
╔═╦╗╔╦╗╔═╦═╦╦╦╦╗╔═╗
║╚╣║║║╚╣╚╣╔╣╔╣║╚╣═╣
╠╗║╚╝║║╠╗║╚╣║║║║║═╣
╚═╩══╩═╩═╩═╩╝╚╩═╩═╝

[ferdinandsteenkamp]

I don't agree that the stdlib handler should return an error, how would that error be handled (other than closing the server)?. I do, however, create my own handler type that returns an error so that I can pass results to middlewares. By not returning an error, the stdlib is forcing you to handle the error...which is the correct behaviour.

[JoeyJurjens]

I agree that you don't need to stop using other routers. However, I've had a few projects now that are fine with those improvements. Dreams Of Code uploaded a video a few days ago, where he went in depth of the new router which also gives examples for middleware chaining & sub routers, which isn't as much boilerplate as you expect.

[JohanStrandOne]

I usually agree with Anthony most of the time but... For once I don't agree with most points he's making.

Opinion incoming:
Anything that doesn't "have to" return an error shouldn't.
Grouping and middlewear is fairly straightforward. Boils down to the fact that I'd rather maintain 20 lines I wrote to hide away whatever annoys me, over depending on a framework.

I do believe there are reasons to use libraries but these aren't the reasons.

Currently my strategy is to go without dependencies until I have a clear reason to add one. I guess I'm old-fashioned 😂

[matiasbpg]

There is no built in grouping, but because mux is a http.Handler, you can make child routers that manage the grouping. For example, config a mux AdminMux :=.... And set it routes. The you can use middlewere for the whole mux ( because it's an http.Handler) and pass this mux to the parent mux for the route /admin/ ( always forget it's the training slash is necessary). You can also omit de admin prefix in the child router bit that requires the extra step of triming the request url with a middlewere before the adminMux can process the request

[vitiok]

Handler functions run as goroutines. There's no point in returning errors. All error handling must be inside. Fiber uses panics to handle those errors. I hate when people use panics as the standard use case. Panic must be the serious exception not the regular error

[potassium]

handlefunc is func what implements handler interface, i think you can change handlerfunc just a little bit for better error handling
you can write your custom HandleFuncWithError just like that:
func (f HandleFunc) ServeHTTP(w, r) {
err := f(w, r)
}

[arturfil]

Any router that adheres to the std lib, a created handler doesn't return an error. The error comes from the service that's called within the handler in any case

[varanasi]

*font size is huge*

for my blind homies!!
LMAO, luv this...

[stefanbogdanovic]

We are using Go Fiber at work, and we are quite satisfied with it, easy to use, has error handler. Love it, good video Antonio :D

[asparkoffire]

Fiber is one of the best frameworks but one of the reasons I switched from Fiber to Gin was that Fiber is built on top of fasthttp which doesn’t support response flushing, and hence there is no easy way to Implement server-sent events (SSEs) in fiber.

[raptorate]

Thank you again for the knowledge, I have taken your advice and playing around with Go + HTMX. For developing and deployment, you advice against containers and I see that you have a WSL Ubuntu installation you directly working in. Could you elaborate why you prefer that way to develop ?

[zema]

Agreed, centralized error handling is not a luxury, it's a necessity for larger projects, I find myself going back to Echo time and time again.

[inaccessiblecardinal]

I'm pleased with the loops versus pointers change. I pulled some code from last year and a func I knew was broken just worked on my new work computer. Wasn't even paying attention, and voila!Almost like I knew what I was doing.

[awesomedavid]

I think it is an improvement, but it still requires a lot of boilerplate. I also prefer handlers that return errors like with Fiber or Echo. It may be a nitpick, but I also don't like how large the parameter types are.

EDIT: yeah, it seems like you agree.

[comedyclub]

I mean, yes, it's not a replacement for the plethora of frameworks out there. But sometimes you want some bare-bones HTTP server with just a handful of fixed routes (e.g. for a simple UI or for providing a websocket server in your otherwise non-web app or something). And for that the changes make things way easier than before.

[edcodes]

I think your wrong about handlers returning errors. Goes against the language design in regards to error handling. It's my personal opinion that it's better to explicitly handle the errors than have some middleware do it, even if writing the code is a little bit tiresome.

[kaspariito]

for the next one -> show how would you build a small vanilla project using mux and new router possibilities, even if not your favorite way to do it :/ :( :) thanks for great content!!

[dcbro]

Write a small wrapper function to handle errors the way you want.

[cureadvocate]

I agree on returning error. Adding a net/http/v2 would be nice, though. Or an adapter on ServeMux to generate an updated mux.

[hobord]

If I have error in handler then I usually do an error reponse (ResponseWriter).
Also I can indicate the error with adding into the request context. If the handler is in the middleware chain...