A comprehensive guide to Go coding standards, architecture, and best practices adopted by Trybe.
betrybe/playbook-go is an internal coding standards and best practices guide for Go development at Trybe. It defines architectural patterns, error handling standards, configuration management, and tooling recommendations to ensure consistency, maintainability, and quality across Go projects within the organization. It serves as a living document tailored to Trybe's specific needs.
Go developers and teams at Trybe who need to adhere to unified coding standards and architectural decisions. It is also relevant for developers outside Trybe looking for a real-world example of a comprehensive, opinionated Go playbook implementing Clean Architecture and structured practices.
Developers choose this playbook because it provides a complete, battle-tested framework for building Go applications with clear separation of concerns, standardized error handling for different consumers (application, user, operations), and integrated tooling. It offers a pragmatic, well-documented approach that emphasizes clarity, consistency, and operational efficiency.
Playbook da linguagem Go
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Defines a comprehensive error type with machine-readable codes, human messages, and operation tracking for application, user, and operational roles, as detailed in the internal/errors/errors.go section.
Organizes code using Clean Architecture principles to separate concerns, improving maintainability with clear layers like entity, usecase, and infrastructure, as shown in the repository structure example.
Uses Viper with environment variables and TOML files for environment-specific settings, following 12-factor app recommendations for consistent configuration across stages.
Employs a monorepo approach with shared internal packages for logging, errors, and middleware, enabling code reuse and easier dependency management across multiple projects.
Specifies preferred libraries like Chi for HTTP routing, testify for testing, and mockery for mocking, reducing decision fatigue and ensuring consistency, with rationale provided in the README.
The monorepo structure admits to complicating CI/CD processes, requiring custom setups for building and deploying multiple apps, which can increase operational overhead.
Openly states 'ORM X SQL' is 'A ser definido' (to be defined), leaving a gap in the architectural guidance and forcing teams to make ad-hoc decisions.
Heavily opinates on specific tools like Chi and testify, which may not suit teams preferring alternatives like Gin or gomock, limiting flexibility.
The detailed error handling and Clean Architecture layers can introduce boilerplate and complexity for simple CRUD applications, potentially slowing initial development.