The product I am building/architecting at work these days uses Monorepo for all our Microservices. Our Microservices are primarily built using Java 17 and Spring Boot 2.6.x. For frontend and platform code(Terraform, Helm charts, configuration files, etc) we have different Git repositories. We use Gradle 7.3 as our build tool. We also make use of shared libraries for code reuse. I know people suggest you should avoid using shared libraries in Microservices but as I discussed in an earlier post I think there are valid reasons to use shared libraries in Microservices.
I prefer Monorepo for three main reasons:
Continue reading “Notes on Gradle Microservices Monorepo setup”
- Better visibility and control.
- Atomic code refactoring across Microservices. This is common in the initial phase of development.
- Easy Code sharing between Microservices
A monorepo is a software development strategy where a single version control repository has source code for multiple projects, libraries, and applications irrespective of their programming language. Also, the organizations using Monorepo strategy often use a common build tool (like Bazel, Pants, Buck) to manage all the source code. Some of the popular examples of organizations that employ monorepo strategy are Google, Facebook, Twitter, Microsoft, and Uber.
Before we start let me give some context on my background so that you can better understand my thoughts on Monorepo.
I head technology at an IT services organization. Most of the products that I build are using Microservices architecture, have multiple frontends(web and mobile). The biggest product that I recently built had close to 30 microservices, 1 web client written in React, and native mobile app built using React Native. These numbers are nowhere near the numbers big product companies have shared.
Continue reading “My Thoughts On Monorepo”
I prefer Macroservices over Microservices. I think most products don’t need more than 10 microservices.