3 ms·

That's the whole point of a monorepo is it not? You get rid of all the ceremony about APIs and just say "Whomever modifies an API is responsible for updating al

That's the whole point of a monorepo is it not? You get rid of all the ceremony about APIs and just say "Whomever modifies an API is responsible for updating all the API consumers as well as the API itself" (and the reverse too). This means that developers are free to write code that is correct now rather than be limited by technical decisions made in the past, that may no longer be valid. It also means that when you do update an API you are confronted with the technical reality of how the API consumers actually work. This may cause you to reevaluate and improve your mental model of the API. If your API is siloed away in its own repo then you can easily get in a position of taking it in a direction that is not actually in line with what API consumers actually need.

rahkiin 5y ago
Whenever you do code updates of separate services, you still need to update all running instances at the same time. Being able to change the code in 1 commit does not necessarily mean the services also update at the same time, which will cause api errors.
- jayd16 5y ago
  If you wanted to you could spin up new clusters of every changed service and direct traffic such that every version of a service is a separate cluster. Then slowly redirect external traffic to new services. Every internal service would always hit the exact version it was compiled with and you only need to worry about external api compatibility at that point. Most use cases you can just get some scheduled downtown, though.
- lhorie 5y ago
  It depends on what kind of APIs we're talking about. There's APIs in the sense of protobuf microservices, which are deployed individually and talk to live systems, but there's also APIs in the sense of libraries. In my company the former is handled by never deprecating any field (and then clients just get to deal with picking and choosing the ones they want). If a major schema change is required, spin up an entirely new service and tell people to migrate over and eventually turn off the old one when nobody's using it anymore. Library changes can be done atomically: change the API, change the call sites, if tests pass you're done. One may opt to use the same strategy as w/ microservices here too. Regardless, the dynamics for interacting w/ microservice API changes doesn't change based on whether you're on a monorepo or not. But a monorepo can help in the sense that some aspects of a service are version-controllable (namely the schema definition files) and it's in the clients' best interest to have those always up-to-date rather than having to remember to run some out-of-band syncing command all the time.
bluGill 5y ago
Common ownership of code doesn't work though. People becomes experts in things they work on a lot, and will refactor better for it because they have long term plans they are working towards. Someone outside making updates will make a mess of the long term plans not understanding where it needs to go.
- cat199 5y ago
  software repositories don't solve process problems in meatspace.
  - bluGill 5y ago
    That is the point. People who claim any repository organization scheme is better are wrong because they can't touch on the real problems.
- JamesSwift 5y ago
  Maybe I missed some implied context, but I would still assume a CODEOWNERs model for the monorepo, wherein _someone_ is the expert/owner of any given folder of code and is brought into conversations when other are touching that code.
  - bluGill 5y ago
    There can be that (should be), but the difference is the code owner isn't making the change, instead the person changing the API is making it.
    - zarzavat 5y ago
      If there's a dispute then a monorepo makes things easier because all interested parties have a complete global view of the entire change. In a multi-repo setup, one change becomes many commits and everybody sees only their piece of the jigsaw puzzle. It does depend on everybody being adults and behaving sensibly; unfortunately there's no technology that can solve that problem.
  - 5y ago

rahkiin 5y ago

Whenever you do code updates of separate services, you still need to update all running instances at the same time. Being able to change the code in 1 commit does not necessarily mean the services also update at the same time, which will cause api errors.

jayd16 5y ago
If you wanted to you could spin up new clusters of every changed service and direct traffic such that every version of a service is a separate cluster. Then slowly redirect external traffic to new services. Every internal service would always hit the exact version it was compiled with and you only need to worry about external api compatibility at that point. Most use cases you can just get some scheduled downtown, though.
lhorie 5y ago
It depends on what kind of APIs we're talking about. There's APIs in the sense of protobuf microservices, which are deployed individually and talk to live systems, but there's also APIs in the sense of libraries. In my company the former is handled by never deprecating any field (and then clients just get to deal with picking and choosing the ones they want). If a major schema change is required, spin up an entirely new service and tell people to migrate over and eventually turn off the old one when nobody's using it anymore. Library changes can be done atomically: change the API, change the call sites, if tests pass you're done. One may opt to use the same strategy as w/ microservices here too. Regardless, the dynamics for interacting w/ microservice API changes doesn't change based on whether you're on a monorepo or not. But a monorepo can help in the sense that some aspects of a service are version-controllable (namely the schema definition files) and it's in the clients' best interest to have those always up-to-date rather than having to remember to run some out-of-band syncing command all the time.

bluGill 5y ago

Common ownership of code doesn't work though. People becomes experts in things they work on a lot, and will refactor better for it because they have long term plans they are working towards. Someone outside making updates will make a mess of the long term plans not understanding where it needs to go.

cat199 5y ago
software repositories don't solve process problems in meatspace.
- bluGill 5y ago
  That is the point. People who claim any repository organization scheme is better are wrong because they can't touch on the real problems.
JamesSwift 5y ago
Maybe I missed some implied context, but I would still assume a CODEOWNERs model for the monorepo, wherein _someone_ is the expert/owner of any given folder of code and is brought into conversations when other are touching that code.
- bluGill 5y ago
  There can be that (should be), but the difference is the code owner isn't making the change, instead the person changing the API is making it.
  - zarzavat 5y ago
    If there's a dispute then a monorepo makes things easier because all interested parties have a complete global view of the entire change. In a multi-repo setup, one change becomes many commits and everybody sees only their piece of the jigsaw puzzle. It does depend on everybody being adults and behaving sensibly; unfortunately there's no technology that can solve that problem.
- 5y ago