4 ms·

I generally agree, but two things I'd like to point out. If you're using python for the web you're already part of the complexity problem, atleast from the per

I generally agree, but two things I'd like to point out. If you're using python for the web you're already part of the complexity problem, atleast from the perspective of someone deploying php 15 years ago. I use python for web development, and I love it, but deploying webpages used to be copy an apache config and ftp/scp your files to some location. Now we need app servers and reverse proxies, and static files are served differently, and even though I've gotten used to it over the last decade it does't mean it's good. The other thing is that MonoRepos are pushing back against complexity for the sake of complexity. Why create a new repo when a directory will work just fine? I think a ton of people got repo crazy because their coporate jenkins server only allowed one project per repo, but it is trivial to check the latest git hash for a directory and base your deployment on that. ...I have a project I inherited that has 14 repos for a webpage with maybe 5 forms on it. I've mostly handed it off at this point, but everytime I have to look at it I end up preaching about monorepos for weeks.

pc86 4y ago
Regardless of how you're deploying things, having unrelated projects in the same git repository might be simpler (maybe?) but certainly seems worse at the same time.
- dec0dedab0de 4y ago
  Regardless of how you're deploying things, having unrelated projects in the same git repository might be simpler (maybe?) but certainly seems worse at the same time. Sure, if they're actually unrelated, or being managed by separate teams then split it up. Though I think the default should be to have one, and split it when there is an actual reason to, especially if it's for the same project. The example I gave wasn't an exaggeration, 14 repos for one project. It was originally built and managed by one person who had them all in the same directory and would open them all in his IDE at once and basically worked on it as a mono repo. After that person quit, when others needed to figure out which repo to clone to fix things it was a nightmare. I know monorepos can be extreme like google, but I just mean one per team, or at least one per project. You shouldn't have to worry about versions of your libraries when there is only one project using those libraries. Edit: For example, a project I did the layout for has a python backend, with a spa frontend, and some ansible playbooks for deployment, integration tests, and a few libraries only used by this project. Each of those 5 things has a top level directory and we deploy a test server for every branch, plus most of us run a local server. We never have to worry about versioning between our own projects, because if they're in the same branch that's the version to use. If we split it into separate repos, then everytime we added a new field to the api, and needed to update the frontend and tests, we would have to manually specify which versions of all the repos go together to build a test server, or to even run a local dev server.
  - ushakov 4y ago
    i'm wondering what engineering decisions drove the project to be split in 14 parts? is it like micro-services thing or what?
    - dec0dedab0de 4y ago
      Yes it was mostly micro services, with a separate frontend repo, and a separate repo for deploy scripts, some separate libraries that were shared between the microservices, there may have even been a separate repo for documentation, I don't remember exactly. I think it really just came down to dividing the repos into chunks that the deployment scripts could use/trigger off of. Instead of developing in a way that makes sense for developers and bending the deployment to fit. Since it was all in one directory on his computer, it was basically a mono repo from his perspective. Committing from the IDE just committed to whichever repo was changed, and since he was the only developer he never saw the downside. When I had to take it over ghorg[0] really came in handy. It's a script to clone all repos from a user/organization on gitlab, github, and others. Then once I opened up all the repos as one pycharm project I was able to get some stuff done, but at that point I might as well just had one repo with a separate directory for each. [0]https://github.com/gabrie30/ghorg https://github.com/gabrie30/ghorg EDIT: I also just remembered that gitlab is much better than github if you are going to go the route of multiple repos for one project. Gitlab lets you create namespaces to group your repos, so if they're all in the same namespace, you could have documentation to just tell people to clone all of them.
  - thebean11 4y ago
    > Sure, if they're actually unrelated, or being managed by separate teams then split it up What if they become managed by separate teams? Or two projects in separate repos become managed by the same team? What about a service that basically everything else in the company relies on (for Google, accounts and auth for example). Better to just keep things in a monorepo IMO, even if they seem unrelated.
    - dec0dedab0de 4y ago
      What if they become managed by separate teams? Or two projects in separate repos become managed by the same team? What about a service that basically everything else in the company relies on (for Google, accounts and auth for example). Better to just keep things in a monorepo IMO, even if they seem unrelated. If there are multiple teams committing to the same repo you need controls over who has permission to commit to which directories and maybe a policy for handling merge conflicts across teams. I'm not sure what the tooling is like around that, but I could see the benefits as long as someone very high up was on board and had enough of a technical mind to keep order. As far as two repos becoming one or one repo becoming two, you can split and merge repos while keeping the commit history. edit: Do you have experience working somewhere with a monorepo that stretched across multiple teams? if so, what was it like?
- zaphar 4y ago
  Why does it seem worse? This is perhaps just each of our individual biases and values hiding behind a preference but I can't identify an objective reason why it's worse other than Jenkins or devtool of choice not handling it out of the box. Don't get me wrong. CI/CD and other dev tools not handling monorepos well is a totally reasonable objective reason to not use monrepos. But it's also mostly about the tool not the monorepo concept itself.
- patrick451 4y ago
  In the last year, there has been a concerted push by certain influential engineers to split our mono repo up. This was first done by splitting things into two repos that were supposedly independent. But they really weren't. Naturally, there was code and configuration that we wanted to be common between the two repos. So now, the solution to every one of these problems is to break off more code its own repo. As the saying goes, as soon as you have two objects, soon you will want a third. It has become a complete nightmare to work with, and as far as I've seen so far has had zero tangible benefits.
rollcat 4y ago
> If you're using python for the web you're already part of the complexity problem, atleast from the perspective of someone deploying php 15 years ago. The problem with deploying PHP is that it immediately gives you something for very little effort, but the effort scales incredibly disproportionately once you outgrow your need for the bare functioning minimum. I personally prefer the "modern" approach of dropping a single, statically compiled binary, which exposes a listening HTTP socket. In case of Go or Rust+Actix, this could sit directly on port 80, but as soon as you add HTTPS, ACME, virtual hosts, etc the story is basically the same regardless of language/framework choice, PHP included.
- dec0dedab0de 4y ago
  Oh I agree, I still get chills when I think about troubleshooting PHP. I was really just making the point that the effort to deploy python as a webapp these days would have been considered overly complex to the average developer 15 years ago. Just how some of the current stuff seems to the OP, so maybe not all seemingly complex stuff is bad.
  - winrid 4y ago
    The debugging story around PHP is better than other major scripting runtimes like Node. With PHP and kcachegrind you can really understand where you're spending CPU easily. The tools for Node work but just aren't there yet. Another nice combo is Java + Mission Control.
    - dec0dedab0de 4y ago
      The debugging story around PHP is better than other major scripting runtimes like Node. With PHP and kcachegrind you can really understand where you're spending CPU easily. The tools for Node work but just aren't there yet. Another nice combo is Java + Mission Control. Fair enough, but I was thinking more along the lines of debugging logic. With python I can open up a local repl or jupyter, run the affected functions/methods, and from there I can get a nice traceback, modify code, or monkey patch something to figure it out. If I can't reproduce the bug locally, I can run a repl directly on the server to see how the code runs differently. My frustration with PHP is just memories of making an edit, refreshing the page, and crossing my fingers. Then once it's working forgetting to save it anywhere else because there wasn't a repo to begin with. I know the tooling has got much better, and PHP developers actually use deployment pipelines these days, and it was mostly caused by myself, and my co-workers not knowing any better. Still just how I remember it. And I don't think I'm the only one.
dolni 4y ago
> If you're using python for the web you're already part of the complexity problem, atleast from the perspective of someone deploying php 15 years ago. [...] deploying webpages used to be copy an apache config and ftp/scp your files to some location. There is a MASSIVE difference in the value proposition of a proper deployment from version control and using something like docker w/ docker-compose to facilitate running your project locally (which is not present in your PHP example) versus what the OP is talking about, which is the idea that you should run EVERYTHING on Kubernetes and write Rust for CRUD apps.
- dec0dedab0de 4y ago
  I mean I tend to agree now, but I don't know how I'll feel in 15 years, I certainly felt much different 15 years ago.
drewcoo 4y ago
Monorepos solve the problem of cross-project "externalities" (sarcasti-quotes) like cross-project testing and CI/CD commonalities.
hcrean 4y ago
I have just finished three years of beating a department of 50 developers into breaking up a fifteen year old mono-repo. The rewards have been quite considerable. Mono repos come with a particular challenge: If you have five projects {A,B,C,D,E} in the same mono-repo, you definitely do not want to be building B,C,D and E every-time someone commits code to project A! This is unimportant at small scales, but as the team grows, building and continuously deploying 'all the things' on every commit just doesn't work out. So the first naive solution is say "we can enumerate all the things that need to be built for project A". This rapidly breaks down when someone figures out they can abstract a shared dependency for A,B and D into some other part of the mono-repo. So now we enter build dependency tools, first Make then some other flavour, then we jump straight to Bazel because someone read about it in a Google publication, then to some custom build scripting because Bazel didn't do this hyper-specific workflow thing someone wanted... In the end maintaining a mono-repo build process becomes a hyper-specialised job function that is almost always kicked to the wayside. In small companies, fewer developers than you can count on your fingers, or truly huge Googles that have their own VCS flavour, it can be shown to work well: But I have yet to hear a story of something in the middle succeeding with a mono-repo.
- mbo 4y ago
  I work for a company with about 1000+ engineers that run a Bazel + Git + GitHub monorepo. As with all workflows it has its painpoints, but I am quite fond of it. It only needs a team of 8 to maintain all the integrations and performance optimisations. GitHub is taking the problems of monorepo user's seriously (https://github.blog/2021-03-16-improving-large-monorepo-performance-on-github/ https://github.blog/2021-03-16-improving-large-monorepo-perf...) and have been responsive to the bugs and poor performance that monorepo's typically cause and exercise.

pc86 4y ago

Regardless of how you're deploying things, having unrelated projects in the same git repository might be simpler (maybe?) but certainly seems worse at the same time.

dec0dedab0de 4y ago
Regardless of how you're deploying things, having unrelated projects in the same git repository might be simpler (maybe?) but certainly seems worse at the same time. Sure, if they're actually unrelated, or being managed by separate teams then split it up. Though I think the default should be to have one, and split it when there is an actual reason to, especially if it's for the same project. The example I gave wasn't an exaggeration, 14 repos for one project. It was originally built and managed by one person who had them all in the same directory and would open them all in his IDE at once and basically worked on it as a mono repo. After that person quit, when others needed to figure out which repo to clone to fix things it was a nightmare. I know monorepos can be extreme like google, but I just mean one per team, or at least one per project. You shouldn't have to worry about versions of your libraries when there is only one project using those libraries. Edit: For example, a project I did the layout for has a python backend, with a spa frontend, and some ansible playbooks for deployment, integration tests, and a few libraries only used by this project. Each of those 5 things has a top level directory and we deploy a test server for every branch, plus most of us run a local server. We never have to worry about versioning between our own projects, because if they're in the same branch that's the version to use. If we split it into separate repos, then everytime we added a new field to the api, and needed to update the frontend and tests, we would have to manually specify which versions of all the repos go together to build a test server, or to even run a local dev server.
- ushakov 4y ago
  i'm wondering what engineering decisions drove the project to be split in 14 parts? is it like micro-services thing or what?
  - dec0dedab0de 4y ago
    Yes it was mostly micro services, with a separate frontend repo, and a separate repo for deploy scripts, some separate libraries that were shared between the microservices, there may have even been a separate repo for documentation, I don't remember exactly. I think it really just came down to dividing the repos into chunks that the deployment scripts could use/trigger off of. Instead of developing in a way that makes sense for developers and bending the deployment to fit. Since it was all in one directory on his computer, it was basically a mono repo from his perspective. Committing from the IDE just committed to whichever repo was changed, and since he was the only developer he never saw the downside. When I had to take it over ghorg[0] really came in handy. It's a script to clone all repos from a user/organization on gitlab, github, and others. Then once I opened up all the repos as one pycharm project I was able to get some stuff done, but at that point I might as well just had one repo with a separate directory for each. [0]https://github.com/gabrie30/ghorg https://github.com/gabrie30/ghorg EDIT: I also just remembered that gitlab is much better than github if you are going to go the route of multiple repos for one project. Gitlab lets you create namespaces to group your repos, so if they're all in the same namespace, you could have documentation to just tell people to clone all of them.
- thebean11 4y ago
  > Sure, if they're actually unrelated, or being managed by separate teams then split it up What if they become managed by separate teams? Or two projects in separate repos become managed by the same team? What about a service that basically everything else in the company relies on (for Google, accounts and auth for example). Better to just keep things in a monorepo IMO, even if they seem unrelated.
  - dec0dedab0de 4y ago
    What if they become managed by separate teams? Or two projects in separate repos become managed by the same team? What about a service that basically everything else in the company relies on (for Google, accounts and auth for example). Better to just keep things in a monorepo IMO, even if they seem unrelated. If there are multiple teams committing to the same repo you need controls over who has permission to commit to which directories and maybe a policy for handling merge conflicts across teams. I'm not sure what the tooling is like around that, but I could see the benefits as long as someone very high up was on board and had enough of a technical mind to keep order. As far as two repos becoming one or one repo becoming two, you can split and merge repos while keeping the commit history. edit: Do you have experience working somewhere with a monorepo that stretched across multiple teams? if so, what was it like?
zaphar 4y ago
Why does it seem worse? This is perhaps just each of our individual biases and values hiding behind a preference but I can't identify an objective reason why it's worse other than Jenkins or devtool of choice not handling it out of the box. Don't get me wrong. CI/CD and other dev tools not handling monorepos well is a totally reasonable objective reason to not use monrepos. But it's also mostly about the tool not the monorepo concept itself.
patrick451 4y ago
In the last year, there has been a concerted push by certain influential engineers to split our mono repo up. This was first done by splitting things into two repos that were supposedly independent. But they really weren't. Naturally, there was code and configuration that we wanted to be common between the two repos. So now, the solution to every one of these problems is to break off more code its own repo. As the saying goes, as soon as you have two objects, soon you will want a third. It has become a complete nightmare to work with, and as far as I've seen so far has had zero tangible benefits.

rollcat 4y ago

> If you're using python for the web you're already part of the complexity problem, atleast from the perspective of someone deploying php 15 years ago. The problem with deploying PHP is that it immediately gives you something for very little effort, but the effort scales incredibly disproportionately once you outgrow your need for the bare functioning minimum. I personally prefer the "modern" approach of dropping a single, statically compiled binary, which exposes a listening HTTP socket. In case of Go or Rust+Actix, this could sit directly on port 80, but as soon as you add HTTPS, ACME, virtual hosts, etc the story is basically the same regardless of language/framework choice, PHP included.

dec0dedab0de 4y ago
Oh I agree, I still get chills when I think about troubleshooting PHP. I was really just making the point that the effort to deploy python as a webapp these days would have been considered overly complex to the average developer 15 years ago. Just how some of the current stuff seems to the OP, so maybe not all seemingly complex stuff is bad.
- winrid 4y ago
  The debugging story around PHP is better than other major scripting runtimes like Node. With PHP and kcachegrind you can really understand where you're spending CPU easily. The tools for Node work but just aren't there yet. Another nice combo is Java + Mission Control.
  - dec0dedab0de 4y ago
    The debugging story around PHP is better than other major scripting runtimes like Node. With PHP and kcachegrind you can really understand where you're spending CPU easily. The tools for Node work but just aren't there yet. Another nice combo is Java + Mission Control. Fair enough, but I was thinking more along the lines of debugging logic. With python I can open up a local repl or jupyter, run the affected functions/methods, and from there I can get a nice traceback, modify code, or monkey patch something to figure it out. If I can't reproduce the bug locally, I can run a repl directly on the server to see how the code runs differently. My frustration with PHP is just memories of making an edit, refreshing the page, and crossing my fingers. Then once it's working forgetting to save it anywhere else because there wasn't a repo to begin with. I know the tooling has got much better, and PHP developers actually use deployment pipelines these days, and it was mostly caused by myself, and my co-workers not knowing any better. Still just how I remember it. And I don't think I'm the only one.

dolni 4y ago

> If you're using python for the web you're already part of the complexity problem, atleast from the perspective of someone deploying php 15 years ago. [...] deploying webpages used to be copy an apache config and ftp/scp your files to some location. There is a MASSIVE difference in the value proposition of a proper deployment from version control and using something like docker w/ docker-compose to facilitate running your project locally (which is not present in your PHP example) versus what the OP is talking about, which is the idea that you should run EVERYTHING on Kubernetes and write Rust for CRUD apps.

dec0dedab0de 4y ago
I mean I tend to agree now, but I don't know how I'll feel in 15 years, I certainly felt much different 15 years ago.

drewcoo 4y ago

Monorepos solve the problem of cross-project "externalities" (sarcasti-quotes) like cross-project testing and CI/CD commonalities.

hcrean 4y ago

I have just finished three years of beating a department of 50 developers into breaking up a fifteen year old mono-repo. The rewards have been quite considerable. Mono repos come with a particular challenge: If you have five projects {A,B,C,D,E} in the same mono-repo, you definitely do not want to be building B,C,D and E every-time someone commits code to project A! This is unimportant at small scales, but as the team grows, building and continuously deploying 'all the things' on every commit just doesn't work out. So the first naive solution is say "we can enumerate all the things that need to be built for project A". This rapidly breaks down when someone figures out they can abstract a shared dependency for A,B and D into some other part of the mono-repo. So now we enter build dependency tools, first Make then some other flavour, then we jump straight to Bazel because someone read about it in a Google publication, then to some custom build scripting because Bazel didn't do this hyper-specific workflow thing someone wanted... In the end maintaining a mono-repo build process becomes a hyper-specialised job function that is almost always kicked to the wayside. In small companies, fewer developers than you can count on your fingers, or truly huge Googles that have their own VCS flavour, it can be shown to work well: But I have yet to hear a story of something in the middle succeeding with a mono-repo.

mbo 4y ago
I work for a company with about 1000+ engineers that run a Bazel + Git + GitHub monorepo. As with all workflows it has its painpoints, but I am quite fond of it. It only needs a team of 8 to maintain all the integrations and performance optimisations. GitHub is taking the problems of monorepo user's seriously (https://github.blog/2021-03-16-improving-large-monorepo-performance-on-github/ https://github.blog/2021-03-16-improving-large-monorepo-perf...) and have been responsive to the bugs and poor performance that monorepo's typically cause and exercise.