Skip to content

Monolithic vs Micro Repos

Gil Tabak edited this page Aug 11, 2019 · 9 revisions

Monotlithic vs Micro Repos

(Starting a discussion here)

This is the guide in which we'll link to several articles pro/con, and try to establish when would it be best to use monolithic repositories and when it would be best to stick with normal, per-app repositories.

We encountered this problem with our own Foresight project, and we're thinking about using a monolithic repo for an upcoming refactoring/splitting of a client's web app into separate services.

Maybe we should not only consider which kind of project it is, but actually consider the current project phase (is it starting? Are the separated app codebases mature enough to work in isolation?) We might consider that a cluster of apps starts as a Monolithic Repo, and at some point it will make sense to split it into multiple repos (when the codebase and external services such as a dependable staging server). Or maybe, the tooling around working with mono repos matures enough to allow the mono repo to continue as such?

Pros vs Cons

Monolithic Repo Pros:

  • A single repo can contain all the related applications.

Monolithic Repo Cons:

  • "humans struggle to tangibly understand domains that are theoretically separate when they are presented as colocated by the source code." (see "Microservices Architectural Patterns" Article)
  • Most of the available CI services won't distinguish / makes difficult to run tests for a particular app in a monolithic repository - we actually have to take notice of this, and facilitate this in our Foresight stuff.

Sources:

Neutral:

Pro Monolithic:

Anti Monolithic:

Clone this wiki locally