The best Go framework: no framework?
threedots.tech
The best Go framework: no framework?
1–10 of 185 posts
Re: The best Go framework: no framework?
#2Since GitHub Copilot, I ditched SQL query builders as all the scanning and repetitive work is handled nearly immediately. I also ditched Chi and handle routing myself. Same for logging.
The issue is spending time doing things that took one line before with a framework (e.g., parsing URL path params). But it's actually satisfying.
Re: The best Go framework: no framework?
#3It makes it easy to get started on a project as there is no time i need to spend thinking about the tools im going to use, its just provided all of them for me, in mostly high quality, relatively easy to use implementations of most basic things.
Re: The best Go framework: no framework?
#4Re: The best Go framework: no framework?
#5https://www.dotconferences.com/2014/10/blake-mizerany-three-...
Of course the only absolute truth is that there are no absolute truths, so no point of being dogmatic to the extreme.
Still, with experience I came to realise that dependencies carry their own weight, which has to be balanced with the weight of bespoke implementation (which can span the whole spectrum from "obviously" to "NIH")
Re: The best Go framework: no framework?
#6I use gin. It's not perfect, especially streaming (EventSource) is broken. But the rest has actual hand on solutions.
ctx.SecureJSON()
Not a single one of the other packages has something like that. Keyword: JSON hijacking protection. Yes it's still a thing.Re: The best Go framework: no framework?
#7Been writing Go for my own pet projects and some production side projects for two years. Often resorted to "small libraries" like Chi, or SQL query builders. Since GitHub Copilot, I ditched SQL query builders as all the scanning and repetitive work is handled nearly immediately. I also ditched Chi and handle routing myself. Same for logging. The issue is spending time doing things that took one line before with a fra…
Re: The best Go framework: no framework?
#8Having an ecosystem of in-house libraries tailored to your products' use cases is not the same as developing an "ad-hoc framework". Where I work, we have several languages deployed in our fleet of microservices. A couple have frameworks, and these frameworks are "try to do it all" types, complete with dependency injection and layer upon layer of abstraction intended to help engineers avoid "needless" boilerplate or what have you. They're slow and difficult to debug/troubleshoot for any case that isn't anticipated by the frameworks, and even sometimes then. No, thank you.
Microservice architecture has its own problems, but these problems tend to be easier to reason about than the services themselves that use the frameworks.