3 ms·
The issue with building a custom monorepo system that can handle Google's and Facebook's scale is that it fails to scale down, even to moderately large project
by scarmig 4y ago
The issue with building a custom monorepo system that can handle Google's and Facebook's scale is that it fails to scale down, even to moderately large project and organizational size. It's expensive (think at least 7 figures opex) and not what most people should be doing.
git, for all its issues (and I'm a git-hater), scales down to an individual coder and scales up (with a lot of hacks, the hacks being used varying depending on whether you're taking a poly or mono approach) to companies that employ thousands of developers.
- andromeduck 4y agoWould be nice if google3 as a service were a thing.
- JTBooth 4y agogoogle3 and Plex! God how I miss working with Plex, I didn't know how good we had it.
- 8n4vidtmkvmk 4y agoPlex the home media server, or something else?
- deleted 4y ago[deleted]
- Rastonbury 4y agoI think it's an internal Google tool
- hbrn 4y agoPolyrepo scales to thousands coders without anyone even noticing, and that's the beauty of it. Just look at the size of node_modules in an average project. You stand on the shoulders of thousands of other engineers and you don't even think about it. That's your polyrepo at work. Now imagine that every time a dependency wants ship a new version, their maintainers have to update all of the dependents. That's your monorepo. It is quite obvious which one is more scalable. The only real benefit monorepo has is that every dependency is always at it's latest version. But the cost to achieve that... let's just say there's a reason you mostly hear about monorepos from Google.