3 ms·

I'm going to play devil's advocate here. As a developer, I quite like monorepos to a certain size (eg: until they get big enough that the tooling we typically

I'm going to play devil's advocate here. As a developer, I quite like monorepos to a certain size (eg: until they get big enough that the tooling we typically use outside of big tech starts to fall down). As an AI, I'm not sure that I care? I'd guess that context management can actually be easier if each microservice has a well documented API (openapi/graphql/grpc/asyncapi/whatever) and you provide the agent harness the ability to drop into each polyrepo as required (and give it the ability to access said documentation). The tedium of making branches / commits / pull requests across 6 repos to land a feature is less problematic to an agent. Admittedly the way I'm using agents at the moment is more repo orientated where it's sandboxed to a single repo, but conceptually I think polyrepo microservices could end up being a sweet spot.

jedberg 2mo ago
> The tedium of making branches / commits / pull requests across 6 repos to land a feature is less problematic to an agent. You're probably not using your microservices correctly if you need to change more than one service at the same time. The whole point of microservices is independently developing and deploying the services. Sweeping changes like that should be done in pieces, one service at a time. Which is why microservices are best for larger organizations, because it reduces coordination between dev groups.
- claytonjy 2mo ago
  if service A calls service B, and service B adds a new endpoint, or a new optional argument, service A needs an update to take advantage of it if a library is used by multiple services, and gets an important bug fix, each service using the library needs to update to get the fix these are sequences of changes, not literally at the same time or requiring deployment coordination, but when this happens a lot people start asking about monorepos
  - jedberg 2mo ago
    But a monorepo wouldn't make any of that easier. You have to make the change to service A and B, and then test both and deploy both. You haven't saved any time or effort in a monorepo. A library needs updating, you still have to update it and then test and deploy every service that relies on it independently. Again you haven't saved any time or effort. In fact you've made it worse, because if those services are maintained by different people, you just forced them to test and deploy on your timeline and priority, not theirs. You actually made the coordination problem worse.
    - mac-mc 2mo ago
      The big thing about monorepos in this case is making a change atomic across a set of projects. Multirepos can't do this 99% of the time and often add a lot more procedure to something close. It's inherently async.
      - jedberg 2mo ago
        > The big thing about monorepos in this case is making a change atomic across a set of projects. The thing microservices is supposed to solve is eliminating the need to make atomic changes across services. There is an inherent overhead in doing that, like making your service support both new and old APIs as long as any service exists using the old API. This is the cost of microservices.
        mac-mc 2mo ago
        The world isn't just backend. There are mobile projects, games, native desktop apps which act together as a suite and web frontends. Also microservices bring up their own host of issues and extra labor. Both are essentially the semantic versioning library update problem, and when you need to propagate a breaking change it create a whole bunch more labor that is significantly reduced in a monorepo vs. a multirepo/microservice world. The tradeoff is you need to invest into repo scaling, much like a backend service that needs to invest in scaling itself too.
    - claytonjy 2mo ago

jedberg 2mo ago

> The tedium of making branches / commits / pull requests across 6 repos to land a feature is less problematic to an agent. You're probably not using your microservices correctly if you need to change more than one service at the same time. The whole point of microservices is independently developing and deploying the services. Sweeping changes like that should be done in pieces, one service at a time. Which is why microservices are best for larger organizations, because it reduces coordination between dev groups.

claytonjy 2mo ago
if service A calls service B, and service B adds a new endpoint, or a new optional argument, service A needs an update to take advantage of it if a library is used by multiple services, and gets an important bug fix, each service using the library needs to update to get the fix these are sequences of changes, not literally at the same time or requiring deployment coordination, but when this happens a lot people start asking about monorepos
- jedberg 2mo ago
  But a monorepo wouldn't make any of that easier. You have to make the change to service A and B, and then test both and deploy both. You haven't saved any time or effort in a monorepo. A library needs updating, you still have to update it and then test and deploy every service that relies on it independently. Again you haven't saved any time or effort. In fact you've made it worse, because if those services are maintained by different people, you just forced them to test and deploy on your timeline and priority, not theirs. You actually made the coordination problem worse.
  - mac-mc 2mo ago
    The big thing about monorepos in this case is making a change atomic across a set of projects. Multirepos can't do this 99% of the time and often add a lot more procedure to something close. It's inherently async.
    - jedberg 2mo ago
      > The big thing about monorepos in this case is making a change atomic across a set of projects. The thing microservices is supposed to solve is eliminating the need to make atomic changes across services. There is an inherent overhead in doing that, like making your service support both new and old APIs as long as any service exists using the old API. This is the cost of microservices.
      - mac-mc 2mo ago
        The world isn't just backend. There are mobile projects, games, native desktop apps which act together as a suite and web frontends. Also microservices bring up their own host of issues and extra labor. Both are essentially the semantic versioning library update problem, and when you need to propagate a breaking change it create a whole bunch more labor that is significantly reduced in a monorepo vs. a multirepo/microservice world. The tradeoff is you need to invest into repo scaling, much like a backend service that needs to invest in scaling itself too.
  - claytonjy 2mo ago