As part of a larger project, my team is building a microservices API layer. We do not have experience with building microservices so we have been trying to figure out how to go about the project.
The first decision we are working on is if we should use a mono-repository or split each microservice into a separate repository. It seems like there are pros and cons to each option.
A mono-repo will increase development time, promote code reuse and make refactoring easier. However, the code base is larger, longer clone time, could run into issues merging and could increase complexity of deployments.
A multi-repo approach will have smaller code bases, less code to clone and will reduce the deployment complexity. However, this approach will increase the development effort. Debugging time can increase and makes it difficult to share common code.
To sum it up, it seems multi-repo is better when the application is in production while a mono-repo is better for development.
With all that said, is there anything else I should consider when deciding whether to use a mono-repo or a multi-repo approach?
Best Answer
When building microservices, we can choose to use a dedicated database for each service or share one database with multiple services. However, the repository code should always belong to only one service. Using microservice, we want to make the development and deployment of each service to be independent of each other. If the repository code is used by two services, these two ones should not be separated.
Normally, I refactor the current application into another monolith one but with better module structure before converting each module into services one by one. Managing dependencies between microservices is always hard and it will become even harder if we let services sharing code.