Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monorepos: Please don’t

medium.com

Post reply on HN
Print view View original

191–200 of 402 posts

Re: Monorepos: Please don’t

#191

Post by rimliu »

fnord123 wrote: post #169
tigershark wrote: post #141

Earlier quoted context omitted.

Not always. It makes absolutely sense to have a repository for the gui and one for the server. When writing a new feature you usually write some gui code and some server code and create different pull requests. I think monorepos are seriously wrong and I completely agree with this article.

>It makes absolutely sense to have a repository for the gui and one for the server. Not really. You can have a single repo with top level directories tigershark-gui and tigershark-server.

And later you add the iOS and Android clients too. Will those go into the same repo? Better to keep server and clients apart, especially if release schedules are different.

Re: Monorepos: Please don’t

#192

Post by Vinnl »

tigershark wrote: post #179
Vinnl wrote: post #162

Earlier quoted context omitted.

Well... Why does that make sense? I have a repository containing both the GUI and the server, and sometimes I have to make changes to both. Locating those related changes together in the same commit and/or PR makes a lot of sense to me: the changes depend on each other, and thus should be reviewed together. What's the advantage of splitting them up?

Because obviously the changes that you make in the gui are completely isolated from the changes you make on the server. When you are working on the gui the server code is just noise and vice versa. And it gets even worse when you use two different languages for the gui and the server.

Hmm, that's not really obvious to me. Sometimes the server has to deliver new data that is to be used in the GUI, so it's nice to be able to present those together in the same PR. If it then happens that the server-side changes do not match what you need in the GUI, it's relatively painless to add those changes in the same branch that hasn't yet been merged. In other words: although you can make changes in one without breaking the other, that doesn't make them completely isolated.

Re: Monorepos: Please don’t

#193

Post by z3t4 »

You can make shallow clones, and auto push to a single repo, it's common to for example auto push to Github from an internal repo. It sure has it's issues, but problems are solved with solutions, simply bury your head in the sand, eg. using single repos where a monorepo is the best solution - is not a solution.

Re: Monorepos: Please don’t

#194

Post by Aeolos »

tigershark wrote: post #179
Vinnl wrote: post #162

Earlier quoted context omitted.

Well... Why does that make sense? I have a repository containing both the GUI and the server, and sometimes I have to make changes to both. Locating those related changes together in the same commit and/or PR makes a lot of sense to me: the changes depend on each other, and thus should be reviewed together. What's the advantage of splitting them up?

Because obviously the changes that you make in the gui are completely isolated from the changes you make on the server. When you are working on the gui the server code is just noise and vice versa. And it gets even worse when you use two different languages for the gui and the server.

> Because obviously the changes that you make in the gui are completely isolated from the changes you make on the server.

In my experience, that is almost never the case. Often, the frontend requires a new endpoint or a modification to an existing endpoint. If you don't coordinate this change, you end up with a non-functional PR that cannot even be tested. Same happens when the backend proposes an endpoint change that affects the frontend.

We have moved the frontend and backend to the same repo to make coordination and testing of such cases simpler.

Re: Monorepos: Please don’t

#195

Post by tigershark »

Vinnl wrote: post #192
tigershark wrote: post #179

Earlier quoted context omitted.

Because obviously the changes that you make in the gui are completely isolated from the changes you make on the server. When you are working on the gui the server code is just noise and vice versa. And it gets even worse when you use two different languages for the gui and the server.

Hmm, that's not really obvious to me. Sometimes the server has to deliver new data that is to be used in the GUI, so it's nice to be able to present those together in the same PR. If it then happens that the server-side changes do not match what you need in the GUI, it's relatively painless to add those changes in the same branch that hasn't yet been merged. In other words: although you can make changes in one withou…

You should always have a communication layer between the gui and the server. For example using protobuf you would update the proto definition (that can be in a shared repo) and when building the gui and the server the protobuf layer is regenerated. So the only place where you make your changes for the new data contract is the shared repo and the gui and server would automatically have the new changes.

Re: Monorepos: Please don’t

#196

Post by Xylakant »

tome wrote: post #152
Xylakant wrote: post #125

Earlier quoted context omitted.

adding raw versions of binary assets (designs, video, ...) can quickly lift a repo beyond a TB. Now, you could say "don't do that", but there's valid use cases where you'd want to track all binary assets as part of the development cycle.

Ouch, well, yes that is a very good situation in which not to take the "mono" part of "monorepo" too seriously.

or use a VCS that allows partial checkouts of repositories. There's no DVCS that I know of that can do that, but for example SVN can. Git LFS might be an option, too. There are also commercial products that target that market.

I just wanted to point out that reaching a measly TB of data doesn't require much effort. (worked on a product that would version rendered clips for special effect production).

Re: Monorepos: Please don’t

#197

Post by lucideer »

forty wrote: post #113
curtis wrote: post #32

My advice is that if components need to release together, then they ought to be in the same repo. I'd probably go further and say that if you just think components might need to release together then they should go in the same repo, because you can in fact pretty easily manage projects with different release schedules from the same repo if you really need to. On the other hand if you've got a whole bunch of component…

My rule of thumb is: if you need to do PRs in several repositories to do one features, you should probably merge the repositories. At work, we have code spread among a bunch of repositories, and having to link to the 2/3 related PRs in other repos is a major PITA, and even more so for the reviewers.

My rule of thumb is: if you need to do PRs in several repositories to do one feature, your projects are either tightly coupled enough that they should be one monolithic piece of software, or your tight coupling is a problem you should work on resolving.

Requiring multiple PRs to multiple repos to roll out one user-facing feature is fine, as long as your independent modules/projects are not actually interdependent (i.e. one of those PRs will not break another independent repo that lacks a corresponding PR).

Re: Monorepos: Please don’t

#198

Post by CJefferson »

Is there any examples of someone who actually maintained a monorepo for a massive company, who now says they shouldn't? It always seems to be "back seat drivers" against monorepo, not people with practical experience (that I can see at least)

Re: Monorepos: Please don’t

#199

Post by matwood »

freedomben wrote: post #42
rgoulter wrote: post #36

Earlier quoted context omitted.

http://wiki.c2.com/?ConwaysLaw "Conway's Law" is something like "organisation of code will match the organisation of people". It's a neat description. I think it's more common to merge or split modules and classes than repositories. I wonder if there'd be less tension if repos and teams were 1:1 though.

> I wonder if there'd be less tension if repos and teams were 1:1 though Anecdotally, yes I think it helps a lot. I was once part of an organization for which each "team" having a repo is the only thing that prevented violence :-)

I've also seen arbitrary separations of repos because 2 people didn't get along and couldn't work together.

Re: Monorepos: Please don’t

#200

Post by atq2119 »

tigershark wrote: post #179
Vinnl wrote: post #162

Earlier quoted context omitted.

Well... Why does that make sense? I have a repository containing both the GUI and the server, and sometimes I have to make changes to both. Locating those related changes together in the same commit and/or PR makes a lot of sense to me: the changes depend on each other, and thus should be reviewed together. What's the advantage of splitting them up?

Because obviously the changes that you make in the gui are completely isolated from the changes you make on the server. When you are working on the gui the server code is just noise and vice versa. And it gets even worse when you use two different languages for the gui and the server.

This is true for systems where there is a well-defined protocol between GUI and servers and a proper versioning process in place, i.e. most "old-school" client/server systems.

I expect lots of people on HN are working on systems with very tight coupling between client/GUI and server and no proper versioning between them, as is common in web applications. Hence the replies to the contrary: you're probably from quite different worlds :)

(Now, I personally think that maintaining sound versioning practices is a good idea even if you do have tightly coupled control of both the client and the server side. But that may just be me...)

Post reply on HN