|
Top-level
 @toby3d Have you considered using a package like gin to help with the web server stuff? I wrote a post here on my findings on other GoLang projects: https://fosstodon.org/@lil5/111380155326273056 If you want someone to look at your code you’ll need to add some readme’s and point them to a specific part of the codebase. 5 comments
@toby3d I’ve always used gin, (because of it’s simplicity) and haven’t come across anything strange 🤷♂️ And for super specific stuff you can always add router group middleware  @lil5 I don't need a whole external dependency just to work with the simple router. The same http.Mux does its job quite well. If for example regular expressions are required to work with collections and objects in them, then there is something wrong in the approach itself. @lil5 And a year of refactoring a huge commercial project single-handedly due to the sudden removal of the #redis package from #GitHub taught me that it's best to keep external dependencies as close to code as possible. Vendoring is extremely useful in self-sufficient programs, especially in CI/CD where there may be no access to the outside world. It is redundant in libraries and embedded packages. @toby3d that’s a good point! Digging deeper vendoring only makes sense for uncommon non-free packages IMO https://stackoverflow.com/a/68544793 > Go Proxy will mitigate disappearing modules to some extent by mirroring modules, but it may not do it for all modules for all time |
Gregory's Server
@lil5 No, in my six years of experience with #Go, I refuse to use web frameworks like #echo, #Gin, #gorilla, #FastHTTP and so on. They only increase the overall complexity of the project and make you struggle with non-obvious limitations.
For example, FastHTTP still doesn't know how to work with fs.FS, and gorilla/mux makes me suffer from regular router configuration problems and search specific gothas.