My name is Emmanuel Katto. I’m currently working on a larger application in Go, and I want to ensure that I structure my project in a scalable and maintainable way. I have a few questions:
What are best practices for organizing directories and files in a large Go project? Are there specific layouts that the community recommends?
How do you typically manage dependencies and versioning in Go, especially for a larger codebase?
Are there particular patterns or architectures (like MVC, Clean Architecture, etc.) that work well with Go that I should consider?
Any guidance or shared experiences would be greatly appreciated!
Every developer and development team will not have the same code style, and there is no perfect best practice. Please be bold and try. If you’re really struggling, you can take a look at someone else’s project code style.
I basically consider whether the dependency library is reliable or not, and if it is not for performance flaws and security vulnerabilities, otherwise I will not upgrade the currently referenced dependency. And if something goes wrong, I’ll look through the source code myself to find the cause.
Think in terms of the direction of the project, not the architecture that determines the project. Architectural feasibility is only considered when the direction of the project requires this architecture.
Most people who ask this kind of question are basically struggling with whether to take a detour before they start writing code. Project refactoring is a normal thing, and you can gain a lot from each refactoring.
I think the root of a project is the business, and even if the code is bad, it’s much better to complete the business requirements than to have no code and can’t get the business done.
I am using “micro services” for isolated tasks. This breaks up a monolith application into small services that can be called when needed and make the main app cleaner.
For an example servers for REST API, Auth, DB setup and upgrade, NATS (pub/sub) and Cron.