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.
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