3 ms·

There would be a mix of versions, managed via branches. The part about debuggability sounded appealing at first, but if the multiple services you want to run a

There would be a mix of versions, managed via branches. The part about debuggability sounded appealing at first, but if the multiple services you want to run are truly that hard to spin up locally, it won't be any easier as a monorepo. First thing you'll do is pass in 30 flags for the different databases to use. If these were RPCs, you could use some common prod or staging instance for things you don't want to bother running locally.

nine_k 2y ago
> There would be a mix of versions, managed via branches "We build the image slated for deployment from the release branch which is cut from master daily / weekly at noon." Works for MPOW, and some previous places. It's a monolith, there are rules! > but if the multiple services you want to run are truly that hard to spin up locally, it won't be any easier as a monorepo. First thing you'll do is pass in 30 flags for the different databases to use. Agreed! Maye that would be a reason to split the thing finally into separate services. Not necessarily micro-services, just into parts that are self-contained enough. But most code bases are not nearly as heavyweight. They can work pretty well as a monolith, run as a whole on a decent laptop, along with a database or two, or even three (typically Postgres, Redis, and Elastic). I know because I did it many times, and a ton of other people did. Worse yet, I ran the whole bunch of microservices, much like production, locally, again, as many a developer here did, too. At the scale this small, the complexity just slows you down. > use some common prod or staging instance for things you don't want to bother running locally. I've seen this in much bigger projects, and there it made complete sense. When you have to move literally a ton, it makes sense to use a forklift. But if the thing is a stack of papers that fits into a backpack, the forklift is an unnecessary bulk and expense. It could sill be a neatly organized stack of papers, not a shapeless wad.
- paperplatter 2y ago
  I'd avoid having separate services share a DB. Besides the overhead, you get scary hidden dependencies that way. If this approach is considered not micro but rather an in-between, the article should mention it as an option.
  - nine_k 2y ago
    Indeed, they should not share a DB (except maybe Redis as a common cache, with a single writer per item type).. But a single Postgres installation can run multiple schemas / users, so you only need to run one Postgres container locally.

nine_k 2y ago

> There would be a mix of versions, managed via branches "We build the image slated for deployment from the release branch which is cut from master daily / weekly at noon." Works for MPOW, and some previous places. It's a monolith, there are rules! > but if the multiple services you want to run are truly that hard to spin up locally, it won't be any easier as a monorepo. First thing you'll do is pass in 30 flags for the different databases to use. Agreed! Maye that would be a reason to split the thing finally into separate services. Not necessarily micro-services, just into parts that are self-contained enough. But most code bases are not nearly as heavyweight. They can work pretty well as a monolith, run as a whole on a decent laptop, along with a database or two, or even three (typically Postgres, Redis, and Elastic). I know because I did it many times, and a ton of other people did. Worse yet, I ran the whole bunch of microservices, much like production, locally, again, as many a developer here did, too. At the scale this small, the complexity just slows you down. > use some common prod or staging instance for things you don't want to bother running locally. I've seen this in much bigger projects, and there it made complete sense. When you have to move literally a ton, it makes sense to use a forklift. But if the thing is a stack of papers that fits into a backpack, the forklift is an unnecessary bulk and expense. It could sill be a neatly organized stack of papers, not a shapeless wad.

paperplatter 2y ago
I'd avoid having separate services share a DB. Besides the overhead, you get scary hidden dependencies that way. If this approach is considered not micro but rather an in-between, the article should mention it as an option.
- nine_k 2y ago
  Indeed, they should not share a DB (except maybe Redis as a common cache, with a single writer per item type).. But a single Postgres installation can run multiple schemas / users, so you only need to run one Postgres container locally.