Monolithic Repository vs Multiple Repositories for a Go Application

This article will use Go as the primary programming language, but many of these concepts are applicable to other languages as well.

There are two ways you can set up your application:

• multiple (microservice) repositories - set it up each component as a package in its own repository.
• monolithic repository - set up all the applications or microservices in the same repository.

There are benefits to each method so you’ll need to decide which is best for your team.

Monolithic Repository

An example of a monolithic repository would be a web application with an Angular frontend, Go API, and multiple Go microservices for loading data into a database.

The benefits of this structure are:

• easy to test all the components in a single CI/CD pipeline.
• all developers work from the same repository so there is better visibility across components.
• simplifies the versioning process since all components are built and distributed together.

Factors to keep in mind:

• standardization is very important because every person will organize differently; spend time developing guidelines for each component so developers can spend less time on design decisions and more time writing productive code.

If you’re building an application with your team that has many components with different technologies or programming languages, you should probably use a monolithic repository. Google, Facebook, and Twitter all use monolithic repositories.

The Go repository on GitHub is a monolithic repository. You can tell because the src folder is in the root of the repository. You cannot use go get on the repository because of this restriction (nor would you want to). The Kubernetes repository is also a monolithic repository, but it does support go get. You can see all the different microservices in the repository by browsing the cmd folder.

Multiple Repositories

An example where multiple repositories could benefit is team is when you are building applications for multiple customers and each one uses the same core, but each requires customizations for each customer. The core could be in one repositories and the customizations for each customer could be in their own repositories.

The benefits of this structure are:

• allows for reuse by other applications via go get or the vendor management tool of choice (as long as there is no src folder in the root of the repository).
• easier to focus on specific components when in a separate repository.
• most Go packages are set up this way so it’s very familiar to developers.

Factors to keep in mind:

• versioning is very important in multiple repositories because any changes to the repository will affect all other applications that are using it; pick a versioning scheme like SemVer (Semantic Versioning) or CalVer (Calendar Versioning), train the team on how to keep a changelog through either issue tracking or manual edits to the changelog file, and then designate a team member to manage the release process.

If you’re building an application with your team that has a specific purpose or is designed to be used as a component of another application, you may want to use separate repositories for each one.

The Gorilla repositories are set up separately so developers can import just the components they wish to use. Buffalo has a few repositories that not part of the main repository.