3 ms·

No! I'm tired of being told how to architect systems because other folks refuse to grow their knowledge. Because I'm good at my job, a monorepo would be pants

No! I'm tired of being told how to architect systems because other folks refuse to grow their knowledge. Because I'm good at my job, a monorepo would be pants-on-head stupid. Because I know how to make separate codebases interact with one another successfully, it would be a massive mistake to lose those advantages, all because you (not me) run into problems when you try to do what I find perfectly natural. And if you work with me, you will learn, and I will guide you, and in time you will experience systems design as I do, and no longer be shackled to only doing the things you understand today. But no, "do this because I don't know how to do that" will never be a winning argument.

lliamander 4y ago
I am myself am skeptical of monorepos, and i have only worked with polyrepos, but I am curious what strategies you use that help make you effective with multiple code bases?
- SpeedilyDamage 4y ago
  Keeping the spirit of microservices alive is super duper important, so not entwining two services with shared code or responsibilities is key, and forcing interaction to happen through their defined APIs.
  - lliamander 4y ago
    Yeah, that's pretty much what I do as well. Shared libraries get their own repo as well and are published in a package manager. Honestly, in terms of enabling concurrent development across multiple teams while simply using common OSS software, polyrepo seems a lot easier.
sanderjd 4y ago
I know how to do that stuff, it just sucks more than having a monorepo with good tooling, in my opinion.
- SpeedilyDamage 4y ago
  In my experience you must write more tooling to get the monorepo to behave as you'd expect, and being able to use off-the-shell tools for CI/CD and orchestration is a huge win vs. having to convince those tools that deploying both the periodic service workers as well as an HTTP backend is actually Totally Normal when it's not.
damethos 4y ago
Loved this comment. We use multi-repos and the only drawback was at the beginning when we were deciding about our linter rules and we had to make multiple PRs (or some other library that had to be stabilized first). Other than that, It never annoyed me in some other way. Independent CI/CD configuration, independent versioning for each repo and independent commit logs are some of the reasons I like it. Maybe everything I mention is simply a tooling problem, but until it exists for us mortals and not just internally for Google, I will stick with multi-repos. I understand the reasoning behind monorepos but it simply is not enough to persuade me at the moment. The only thing that I would like us to solve with a tool when it comes to the multi-repos, is to force which versions of the separate repos are compatible together. For the time being it's manageable without automation but it's definitely a high priority. EDIT: Added new paragraph

lliamander 4y ago

I am myself am skeptical of monorepos, and i have only worked with polyrepos, but I am curious what strategies you use that help make you effective with multiple code bases?

SpeedilyDamage 4y ago
Keeping the spirit of microservices alive is super duper important, so not entwining two services with shared code or responsibilities is key, and forcing interaction to happen through their defined APIs.
- lliamander 4y ago
  Yeah, that's pretty much what I do as well. Shared libraries get their own repo as well and are published in a package manager. Honestly, in terms of enabling concurrent development across multiple teams while simply using common OSS software, polyrepo seems a lot easier.

sanderjd 4y ago

I know how to do that stuff, it just sucks more than having a monorepo with good tooling, in my opinion.

SpeedilyDamage 4y ago
In my experience you must write more tooling to get the monorepo to behave as you'd expect, and being able to use off-the-shell tools for CI/CD and orchestration is a huge win vs. having to convince those tools that deploying both the periodic service workers as well as an HTTP backend is actually Totally Normal when it's not.

damethos 4y ago

Loved this comment. We use multi-repos and the only drawback was at the beginning when we were deciding about our linter rules and we had to make multiple PRs (or some other library that had to be stabilized first). Other than that, It never annoyed me in some other way. Independent CI/CD configuration, independent versioning for each repo and independent commit logs are some of the reasons I like it. Maybe everything I mention is simply a tooling problem, but until it exists for us mortals and not just internally for Google, I will stick with multi-repos. I understand the reasoning behind monorepos but it simply is not enough to persuade me at the moment. The only thing that I would like us to solve with a tool when it comes to the multi-repos, is to force which versions of the separate repos are compatible together. For the time being it's manageable without automation but it's definitely a high priority. EDIT: Added new paragraph