At work, I was recently introduced to the idea of Monorepos. While developer who have been writing code for microservices tend to think of microservice architecture as a number of x codebases somehow interacting with each other, there is another school of thoughts that is pushing the idea of organising code in a single repository. Do not fret, that does not mean that we want to create a monolithic application, tightly coupled, aka a giant and far from being modular piece of software. It only means that, instead of having the code residing in different repositories and having to tweak and make changes in each of one making sure that integration tests are still green and happy, everything is in one codebase and it generally holds the following features:
- Only build the services or cmds that are modified in a pushed commit;
- Build all services and/or cmds that are affected by changes in common codes (i.e.
pkg); - Build all services and/or cmds that are affected by changes in
vendorcodes.
https://medium.com/goc0de/how-to-golang-monorepo-4f62320a01fd
https://circleci.com/blog/monorepo-dev-practices/
https://hardyantz.medium.com/getting-started-monorepo-golang-application-with-bazel-370ed1069b4f