Hacker News Reader

Comment by veidr | Hacker News Reader

This article sucks. Does your company have tens of thousands of employees? If so, hopefully you have some engineers working on your tooling. If not, you don't have the problems described here, and you will also happily get all the "theoretical benefits" that this guy apparently didn't experience.

Moving to monorepo is often a win; also the name sucks, we have a a few "monorepos" at work, and I think it's the sweet spot. Rust and C firmware doesn't need to live with TypeScript frontend apps, but it's pretty wasteful to have apps of the same ecosystem unable to share any and all dependencies and utility code trivially.

(Where "trivially" means literally one line of code

    import { bleargh } from 'hoge';

and not one single step more.)

View on HN

I've been saying "megarepo" because I tend to split things into a few large groups and then have dedicated repos for places it makes sense

I will start saying this, too. :)

Instead of e.g., "blah blah blah a monorepo — not necessarily a literal monorepo in terms of having only one repo with every single project in it, but a repo in which several related projects are colocated, and that uses some kind of monorepo tooling like Nx to avoid redundant work — blah blah blah".

I'd love to learn more about anyone using mono repos for small to medium projects.

This article is also 5 ish years old and I would hope some of the tooling for bigger orgs has started to make it downstream since then.

As parent comment mentioned, scaling welcomes teams to work on tooling.

A mix of Gitlab overall with some Gitolite to manage access to certain branches of the repo if needed seem to be one way to go.

You can npm install repositories, no need to merge frontend and backend just to share code. Break out what can be shared into utilities and you can share it in completely unrelated projects as well.

I get monorepos for SSR and the likes but why build and deploy an entire container to push a line of CSS?

Polyrepo ends up with a mess of version management and flood of PRs to roll out minor changes

Imagine adding a field to a table that must be reflected in the front end and some other micro service consumers. Coordination can be painful.

Each system has its pros and cons, you're going to need tooling either way. I've moved to mono or mega repo as the default and break out smaller pieces into dedicated repo as needed

I get the feeling what you call a monorepo is microscopic compared to what the article is discussing.

Your monorepo sometimes approach is the polyrepo approach.

You're going to have to edit the code in 2 places either way. With a sane deployment strategy the backend would have the extra field, then you can deploy the frontend to render said change. Or sometimes the table is dynamic and doesn't even need changes on the frontend.

To me the ability to push changes independent of other pieces far outweighs the extra git commit and push. I've never had the need for any other tooling than a container to run in, git to manage code, and CI/CD for deploys. If there's a need for special tooling to manage the projects there's to much complexity for my taste and I remove the complexity instead.

At work, I pushed for a monorepo. We deploy everything as docker containers, both the backend, the frontend and the services. Each service imports and compiles what it needs, nothing more.

We could look to deploy CSS in a different way to optimize the use case for updating a single CSS line, and deoptimize everything else.

I don’t understand why deployment approach is related to mono vs multi repo?

Read the comment I'm replying to and you'll see the context, a single deploy for changes on backend and frontend is mentioned as a benefit. I'm suggesting deploying in order so a frontend doesn't expect a field that doesn't yet exist on the backend.

Nothing in any of these comments suggests you need to deploy in any particular order, or that you need to group any particular code together in order to deploy it.

Monorepos make sharing code easier. They don’t put any requirements on deployment. You can make good or bad decisions regarding deployment when using monorepos or multiple repos.

How do you share config files, protobuf schema, etc. between frontend and backend if you have different repos for each?

I have only worked in large codebases with monorepo, so I'm curious.

You build a package and publish it to a private registry, so builds can reference specific versions of dependencies from other repos.

We use a jenkins job that watches the “source of truth” repo, which in our case is the backend.

Jenkins creates all the protobuf definitions and pushes them to their dependent repos.

A better way would be with a package repository for them, and having it versioned; and running multiple versions of the backend.

Reply on news.ycombinator.com