Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Quite a premise: "Giant monolithic source-code repositories are one of the fundamental pillars of the back end infrastructure in large and fast-paced software companies."


facebook, google, airbnb, quora, many more all use monorepo

obviously there are many others who do not use monorepo (amazon comes to mind) but it's reasonable to claim that they are actually widely used and fundamental when used


Microsoft uses it for Windows as well, which was so large they wrote their own git filesystem to power it.


Does anybody know how these companies development environments look like? I know about Piper at Google but how do the rest manage? Does every single engineer have the entire monorepo in their machines?


At facebook, a virtual filesystem (https://github.com/facebookexperimental/eden) + change monitor (https://facebook.github.io/watchman/) = source control operations run in O(files I have modified) instead of O(size of repository) time


Very interesting, thanks!


Most places I know of use Git Virtual File System or equivalents.


It is my understanding that VFSForGit only works on Windows.


The github repo has instructions for running it on Mac and says that the stable Mac version is under active development.


Airbnb uses a monorepo for JVM-based project but most of Airbnb's code at least as of mid-2017 was not run on the JVM and was hosted multi-repo.


What are AirBnb's unique scaling issues other than just being a web app with tons of usage?

Uber has navigation, route optimization, queuing, etc. Facebook has to propagate activity our to massive and complex social network graphs.

I'm not discounting the toughness of operating at Airbnb's scale, but from my limited understanding it seems like they are not solving a new problem.


Map search, automatic dynamic pricing, predicting busy periods, predicting user & provider preferences, etc.


i was a data scientist so i knew of monorail but never touched that side of things :)


Notably, Netflix doesn't (or least didn't):

https://medium.com/netflix-techblog/towards-true-continuous-...


til! Most of my experience with large, single-repository projects are just plain monoliths. The design goal we strive for tends to be the microservice architecture, assuming that isolation of responsibility leads to more maintainability, better decision making, etc. I can see how, with a well disciplined team, the monorepo could have the best of both worlds.


Many companies do use a monorepo. Many other companies do not. There are trade offs.


All the companies have in common a huge budget they can invest on their build systems to overcome the shortcomings of monorepos.

They do have some benefits, but they also come with an immense cost


But that's what the OP's quote is saying. "large" companies use them.


all of those companies were once small too


I like it at Google!


Google has the team + tooling to properly support it. The same cannot be said for many other orgs.


Google has more people working on the problem than many other companies have employees.


I don’t doubt it. They also do more traffic through their VCS than most companies do through their main product.


Do they? They didn't used to. In 2015 we were routinely dead in the water, unable to test and deploy anything from our google3 projects because some random submitted a CL for a project we didn't even care about. Teams would appoint "build cops" whose job is to complain as quickly as possible because that's all we could do about it.

Every problem you could have with bad dependencies is entirely self-inflicted. The Right Thing™ is to choose a known-good version, and update when you have the bandwidth to pay down the tech debt.


Many teams


Yes, my first thought "I wish the systems I worked on in big corps were big monolithic giants"


Which huge successful software companies don't use a monorepo?


Amazon.


I think these count as huge (although maybe not when next to Google), but Spotify and Netflix.


I'm willing to agree with that premise.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: