
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.

When it’s worth to write low-quality code
Quick Takeaways High-quality code is mainly about keeping good iteration speed over time - can you add features without breaking what works? Not all code needs to be high quality - focus your efforts on the code that’s most important, changes often, or creates the most value. The right time to refactor is after you know your product has value, but before technical debt gets too big - make small improvements bit by bit.
Series
Popular articles
- The Go libraries that never failed us: 22 libraries you need to know
- Safer Enums in Go
- Common Anti-Patterns in Go Web Applications
- How to implement Clean Architecture in Go (Golang)
- The Repository pattern in Go: a painless way to simplify your service logic
- Introduction to DDD Lite: When microservices in Go are not enough
Tags
- go
- golang
- watermill
- ddd
- clean-architecture
- domain-driven design
- events
- web-applications
- anti-patterns
- ci
- firestore
- cloudrun
- gcloud
- googlecloud
- serverless
- testing
- advanced
- databases
- devops
- event-driven
- firebase
- gitlab
- microservices
- reactive
- repository
- architecture
- backend
- basics
- building-business-applications
- building-in-public
- cqrs
- frameworks
- kafka
- mysql
- nats
- pipelines
- scalability
- software-architecture
- software-development
- transactions
- amqp
- authentication
- balance
- bounded-context
- c4
- cicd
- code-quality
- design-patterns
- diagrams
- docker
- dry
- e-book
- efficiency
- enums
- event-storming
- gamedev
- generics
- google-cloud
- grpc
- htmx
- intermediate
- iteration
- javascript
- learning
- libraries
- maintainability
- metrics
- monolith
- openapi
- over-engineering
- overengineering
- parallelism
- productivity
- programming-languages
- prometheus
- python
- rabbitmq
- retrospective
- security
- sql
- sse
- startups
- strategic-ddd
- swagger
- terraform
- tips
- unpopular-opinions
- versioning