I’m not sure it was posted here so I figured I would post it. As of Dec 9, 2022 the entire gorilla toolkit is in archive mode:
There’s a lot of good discussion on this reddit post:
I’m interested in hearing your reactions to this with regard to how it affects projects using the gorilla toolkit. I’m probably not going to use
gorilla/websocket going forward (seriously, though, what’s the alternative right now?) since that will probably need to change over time. However, I have several projects using
gorilla/mux and I’m not sure I will be migrating them to something different for the foreseeable future. I mean - how often does an http router really need to change?
For new projects, it’s probably safe to still use
gorilla/mux if you’re familiar with it. It’s used by a lot of projects and I have to imagine somebody is going to fork/maintain it. I’m leaning towards julienschmidt/httprouter for most of my new APIs (or stdlib). But I’m curious to know what other people on the forum are doing.
As a newbie I find the built in ServeMux is sufficient for my needs. And I find it both simpler and more flexible both for web sites and API. I have tested both gorilla and fasthttp, but I find them backwards logic to a fresh Gopher. I never got them to work…
For simple or temporary projects I’d use the easy way to go (
gorilla/mux, …), since the risk is not relevant and requirements are few. Between the well tested and popular routers instead, I’d choose Chi, because it’s light, stdlib friendly, clean, actively maintained and if you want you can also import and use all the other components. httprouter is great and a bit more performant than chi, but it seems, at least from what I see, that it’s also be on the same way as gorilla about GitHub activity, and I don’t like having this risk at all when I think about starting a new project that will possibly be in production for a long time.
Speaking about websocket I’m not convinced about others resources and if I had to need it now, I would still use gorilla, I think…
I haven’t used Chi yet but I have noticed it has a lot of activity and it seems like a lot of people are using it for new projects. I might check that out next time I’m spinning up a new API.
Yeah - in the official websocket repo I noticed they removed the link to gorilla/websocket. Now they recommend nhooyr.io/websocket, which isn’t super active but at least has some activity. Per the readme:
note: I haven’t been responsive for questions/reports on the issue tracker but I do
read through and there are no outstanding bugs. There are certainly some nice to haves
that I should merge in/figure out but nothing critical. I haven’t given up on adding new
features and cleaning up the code further, just been busy. Should anything critical
arise, I will fix it.
I’m guessing this is the best option for now. I’ve never used it though and gorilla/websocket was pretty easy/ergonomic to use.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.