yeah, I’ve been wondering about that. gorilla was so popular for so long, and now it’s eol. I know I’ve used it in professional projects. I guess everyone saying to just use the standard library were proved right in this scenario. Not that it’s a huge deal though, the code still works.
There’s a pretty large collection of routers in go, probably in no small part because of how easy it is to do with the standard library; Flow is ~160 lines of code. Carlmjohnson who posted original last year ended up writing their own router as well.
To add another to the list Labstack’s Echo is probably my personal favorite.
That’s the biggest problem with Go. Things are so “easy” that everybody writes stuff themselves and then they end up with a pile of code (for better or worse).
IMHO this article (and the flow chart) is flawed, since there is no “do not use a router” option. Many (even more complex) use cases do not need a router. Adding a dependency is almost always worse than adding a few lines of manual code to do something simple yourself. A router is just a helper that facilitates “if-then-else” flow. If you have a tiny web server, don’t use a router. That’s just my opinion though.
There’s a large chunk near the beginning of the article which starts with “I’ll start by saying that if you can use http.ServeMux, you probably should.” and goes on to say “In fact, the only time I’d recommend not using [http.ServeMux] is when you need support for variables in URL paths or custom routing rules.”
I have used a few of those mentioned in the article, the one I have settled with is chi. It uses the standard library and the code is “easy” to read and follow. I use it in all my API projects.
I really enjoy using go-chi. It’s straight forward but has options for complex use cases. It uses the handler from the standard library so it integrates well with everything. It also comes with middleware, which is easy enough to use, or to crib of off to write your own.
From 2021 and perhaps not relevant as mux is eol?
https://github.com/gorilla/mux
yeah, I’ve been wondering about that. gorilla was so popular for so long, and now it’s eol. I know I’ve used it in professional projects. I guess everyone saying to just use the standard library were proved right in this scenario. Not that it’s a huge deal though, the code still works.
Fair enough, but I posted this because another article about Go routing was on the front page—and it was from 2020.
Article author took best of both approach and wrote Flow: https://www.alexedwards.net/blog/introducing-flow
There’s a pretty large collection of routers in go, probably in no small part because of how easy it is to do with the standard library; Flow is ~160 lines of code. Carlmjohnson who posted original last year ended up writing their own router as well.
To add another to the list Labstack’s Echo is probably my personal favorite.
That’s the biggest problem with Go. Things are so “easy” that everybody writes stuff themselves and then they end up with a pile of code (for better or worse).
IMHO this article (and the flow chart) is flawed, since there is no “do not use a router” option. Many (even more complex) use cases do not need a router. Adding a dependency is almost always worse than adding a few lines of manual code to do something simple yourself. A router is just a helper that facilitates “if-then-else” flow. If you have a tiny web server, don’t use a router. That’s just my opinion though.
There’s a large chunk near the beginning of the article which starts with “I’ll start by saying that if you can use http.ServeMux, you probably should.” and goes on to say “In fact, the only time I’d recommend not using [http.ServeMux] is when you need support for variables in URL paths or custom routing rules.”
I have used a few of those mentioned in the article, the one I have settled with is chi. It uses the standard library and the code is “easy” to read and follow. I use it in all my API projects.
I really enjoy using go-chi. It’s straight forward but has options for complex use cases. It uses the handler from the standard library so it integrates well with everything. It also comes with middleware, which is easy enough to use, or to crib of off to write your own.
At my company our recommended router is chi for new projects, where we were using gorilla/mux previously