<story><title>Go in Production – Lessons Learned</title><url>https://tdom.dev/go-in-production</url></story><parent_chain><item><author>ldelossa</author><text>The more you get to know Go&amp;#x27;s stdlib the less and less youll think a web framework is necessary.&lt;p&gt;Youll find that utilizing http Round Tripper along with the Handler interface in the http library will make middleware easy.&lt;p&gt;Youll eventually dig into filepath and path methods for extracting path parameters from url paths.&lt;p&gt;And logging and recovery will be a concept youll need to extend outside of just http and into the rest of your application.&lt;p&gt;I totally advise new comers to use a web framework, but in the long run, you probably wont want too.</text></item></parent_chain><comment><author>willsewell</author><text>I see this sentiment a lot in the Go community. I think it is reasonable in some cases, but there are many use cases (vanilla CRUD web apps) where a web framework is really helpful.&lt;p&gt;The standard library is very low level. Want sessions? DIY. Want user auth? DIY. Want CSRF protection? DIY. The list goes on.&lt;p&gt;It feels like a waste of time implementing these &amp;quot;solved problems&amp;quot; from scratch, but the biggest problem is how easy it is to introduce security vulnerabilities when implementing from scratch, or forgetting to do so.&lt;p&gt;It’s nice to learn concepts from first principals by using the standard library. But once I know how these things work, I’d rather rely on someone else’s battle tested code and best practices.&lt;p&gt;Yes, you can add in separate libraries to solve these specific problems, but they are less likely to compose as well as they would in a framework. On top of this, each time you pull in a new library you have to spend time evaluating it. When I use a framework I don&amp;#x27;t have to think.</text></comment>
<story><title>Go in Production – Lessons Learned</title><url>https://tdom.dev/go-in-production</url></story><parent_chain><item><author>ldelossa</author><text>The more you get to know Go&amp;#x27;s stdlib the less and less youll think a web framework is necessary.&lt;p&gt;Youll find that utilizing http Round Tripper along with the Handler interface in the http library will make middleware easy.&lt;p&gt;Youll eventually dig into filepath and path methods for extracting path parameters from url paths.&lt;p&gt;And logging and recovery will be a concept youll need to extend outside of just http and into the rest of your application.&lt;p&gt;I totally advise new comers to use a web framework, but in the long run, you probably wont want too.</text></item></parent_chain><comment><author>pjmlp</author><text>Here is the thing, I have been doing Web development alongside native for a couple of decades now.&lt;p&gt;This Go enlightment seems to only touch those that don&amp;#x27;t realize that programming to interfaces was already a thing back in Objective-C and WebObject days, or using Smalltalk categories (later formalized as traits in Pharo).&lt;p&gt;Also that languages like Java and .NET also have a similar Http server on their standard library since Java 6 (2006) and .NET 2.0 (2002).&lt;p&gt;The reason we don&amp;#x27;t use them beyond toy examples, is that they don&amp;#x27;t scale when things start getting hard and something like IIS, ngix or similar is called into action.</text></comment>