Image for post
Image for post

So this is the second post about monorepos. The first post was about Google Bazel, this one is about Facebook Buck. IMHO Monorepos makes all the sense for Mobile(Ios and Android) since it’s all about the same application. Of course, if you have libs that can work across multiple platforms(built-in C) or similar which make sense have generic repos outside of the app monorepo. At least one app should have a monorepo. I also believe a similar strategy can be applied for SOA and Services where we could have one monorepo per business domain. In that case, we would reduce the number of microservices drastically but still work with modules. For this post, I want to share another post. We will build a monorepo with Buck and Java. Facebook Buck is very similar to google Bazel on usage and principle. So without further due Let’s get started.

Related Reading

This blog post is also related to previous Architecture blog posts I made in regards to Microservices, SOA, and Shared Internal Libraries. I highly recommend you take a look:

The Death of microservices — Distributed Monolith 101

London Meetup — The Death of microservices VIDEO

Shared Libraries Trap

Sidecar Pattern

Double Down on Service Orientation

The Video

The Code


Diego Pacheco

Originally published at on December 9, 2020.

Brazilian, Software Architect, SWE(Java, Scala, Rust, Go) SOA & DevOps expert, Author. Working with EKS/K8S. (Opinions on my own)

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store