4 ms·

The article doesn’t have any connection to monorepo / polyrepo axis. You can use either repo structure for a monolith application, or use either repo structure

by mlthoughts2018 6y ago

The article doesn’t have any connection to monorepo / polyrepo axis. You can use either repo structure for a monolith application, or use either repo structure for separated microservices. The article is just not related to repo structure in any way.

k__ 6y ago
I'd say, that's the problem with that article.
- mlthoughts2018 6y ago
  That wouldn’t make sense, given that repo structure truly is unrelated in any way to the distinctions between monolith applications vs microservices.
  - k__ 6y ago
    But it is. If you have multiple services in one repo it's much easier to work on each of them.
    - mlthoughts2018 6y ago
      No, it is not easier. Working on them across multiple repos is just as easy. In either case you write dev tools to apply changes across units. If the units are repos, it adds no additional complexity.
lllr_finger 6y ago
The article isn't related to repo structure, however repo structure can relate to the core issue of how to share code and maintain domain boundaries - search for the "umbrella" thread elsewhere in these comments.
- mlthoughts2018 6y ago
  Just because repo structure can relate doesn’t mean that such a relationship involves any properties of monorepo structure vs polyrepo structure. Any messy code organization or dependency issue you can have in a monorepo, you can also have in polyrepos. Any automation or central controllership you can have in a monorepo, you can also have in polyrepos. Any scale-out chores or overhead work you can have with polyrepos, you can also have with monorepo. The issues of monolith / poorly coupled dependency applications vs microservices has absolutely nothing to do with monorepo vs polyrepos. Neither option makes any class of tooling easier / harder to build or maintain. Neither makes conceptual organization easier / harder to get right, neither makes discoverability or cross-referencing easier or harder. That whole axis of concern is just fundamentally unrelated to the application monolith vs microservices question.

k__ 6y ago

I'd say, that's the problem with that article.

mlthoughts2018 6y ago
That wouldn’t make sense, given that repo structure truly is unrelated in any way to the distinctions between monolith applications vs microservices.
- k__ 6y ago
  But it is. If you have multiple services in one repo it's much easier to work on each of them.
  - mlthoughts2018 6y ago
    No, it is not easier. Working on them across multiple repos is just as easy. In either case you write dev tools to apply changes across units. If the units are repos, it adds no additional complexity.

lllr_finger 6y ago

The article isn't related to repo structure, however repo structure can relate to the core issue of how to share code and maintain domain boundaries - search for the "umbrella" thread elsewhere in these comments.

mlthoughts2018 6y ago
Just because repo structure can relate doesn’t mean that such a relationship involves any properties of monorepo structure vs polyrepo structure. Any messy code organization or dependency issue you can have in a monorepo, you can also have in polyrepos. Any automation or central controllership you can have in a monorepo, you can also have in polyrepos. Any scale-out chores or overhead work you can have with polyrepos, you can also have with monorepo. The issues of monolith / poorly coupled dependency applications vs microservices has absolutely nothing to do with monorepo vs polyrepos. Neither option makes any class of tooling easier / harder to build or maintain. Neither makes conceptual organization easier / harder to get right, neither makes discoverability or cross-referencing easier or harder. That whole axis of concern is just fundamentally unrelated to the application monolith vs microservices question.