When you shouldn’t use frameworks in Go

Quick takeaways

• Frameworks promise productivity but often lead to issues as projects get larger and more complex.
• The Go community prefers small, focused libraries over frameworks due to Go's design philosophy influenced by Unix principles.
• Watch out for risks using frameworks like vendor lock-in, deprecation, and costly migrations that can take months.
• Explicit code is more maintainable than magic framework abstractions.
• Choose your approach based on project size and maturity - frameworks might work for prototypes, while modular libraries are better for long-term projects.

Introduction

In this episode of the No Silver Bullet podcast, we discuss frameworks in Go and when they're useful or problematic.We talk about why the Go community generally avoids frameworks compared to other languages, and how small, modular libraries are often preferred in Go development.

We share our experiences with frameworks across different projects, including tradeoffs between productivity and long-term maintenance.

Notes

• Model-View-Controller (MVC): Pattern first described in the 1970s for Smalltalk, still widely used today.
• Unix Philosophy: https://en.wikipedia.org/wiki/Unix_philosophy: design concept created by Ken Thompson (also a Go creator) promoting small programs that do one thing well and work together.
• When to avoid DRY in Go: https://threedots.tech/post/things-to-know-about-dry/
• Watermill: https://watermill.io: Our event-driven library for Go designed to not be a framework.
• Repository Pattern: https://threedots.tech/post/repository-pattern-in-go/: Our blog post that is still relevant and frequently referenced.
• tdl: https://github.com/ThreeDotsLabs/cli and pq: https://github.com/ThreeDotsLabs/watermill/tree/master/tools/pq - the CLI tools we mentioned.
• Clean Architecture: https://threedots.tech/post/introducing-clean-architecture/: The topic of our next podcast episode, a design approach that helps maintain separation of concerns.
• Wild Workouts: https://github.com/ThreeDotsLabs/wild-workouts-go-ddd-example : Our example Go codebase demonstrating clean architecture.  
• The Best Go framework: no framework?: https://threedots.tech/post/best-go-framework/
• 
  

Quotes

The happy path is easy enough, but the happy path is usually not the hard part of software. We often overvalue how much effort the boilerplate requires. - Miłosz

Framework knowledge tends to become out of date. You can spend days or weeks learning something about a framework, but it can be outdated. And if you switch to another programming language or company, a lot of effort that you spent to learn stuff will be just wasted. - Robert

It's more important to learn even-driven architecture because you learn the theory behind it and how it works in general - it transfers better to whatever you will do later. Focus on timeless skills like how to split modules in your application, how to make it decoupled, how to write business logic so it's easy to read and modify. - Miłosz

The Go language is heavily influenced by Unix philosophy - write programs that do one thing and do it well, write programs that work together. It's visible in Go's standard library. This is why Go promotes building independent components that you can connect together. - Robert

You need to be careful not to go too far with foundations. It's better to start with some modular libraries, have some reasonable setup in place, but don't go too crazy with it. Most of the time you'll need to refactor the project anyway, whatever you do, because it can change drastically. - Miłosz

One big decision at the beginning may cost you six months of work later. Understanding if something is tightly coupled to your application is simple - just think about how easy it would be to remove it. - Robert

Full episode notes: https://threedots.tech/episode/when-you-should-not-use-frameworks/