I'm curious how many of you (and how, if so) use a monorepo. Do you use it for both backend and frontend? Do you use any tools to help you with that?
I would be grateful for your answers.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (19)
I've used it twice commercially, 1 fail and 1 success.
My TL;DR opinion
For small teams with highly mutable code bases it is convenient, especially in the first couple of stages of life for commercial projects. Less parts, more speed!
For large teams/application it quickly becomes a testing nightmare where everyone hates that team that broke their feature, again.
The large team/application problem can be mitigated, but to do it you need dedicated technical leads or an experienced team on top of enforced standards.
Here are my experiences from different points in my career.
Company 1:
As a intermediate developer i worked in a team of
15-25+ people in a repo', with very unrelated parts that would break frequently when common code was touched. Enforcing coding styles was a nightmare because of how many people you needed to include. The performance was out of control because we could not isolate parts or make informed group decisions on libraries.
Developer experience was from junior to intermediate, and 1 socially inept senior.
Everyone making technical decisions and working their own patterns rather than a common one.
Making releases was problematic, and feature integration bugs were rampant, mitigated by a large QA team.
Worth mentioning, technical leadership was basically non-existent here, leading to constant chaos.
Company 2:
As a senior developer i worked in a team of
10-15 people working in a repo', 3 teams each responsibly for a isolated part of the code-base, and only senior developers with a high focus on performance and maintaining standards, i would go as far and say we had a performance culture.
It worked well, mostly because each part we made was mostly isolated, so breaking unrelated parts was uncommon unless you bodged a bug-fix for a library part.
Technical leadership was also missing in this case, but mitigated by the number of seniors, culture, smaller team and somewhat smaller code-base.
I have experienced this. Is it really a mono repo if there is one monolithic application though? One app per repo I would just say is a normal repo.
Afaik mon-repo refers to the practice of having all related application code in the one (mono) repo.
vs separating API's, libraries, etc. into different repositories.
Am i wrong about that interpretation?
You are right tho, the first example would not fit that description strictly, as some dependencies were external (Authentication and API).
It did encompass several unrelated web applications in the same codebase however.
My second example contains all the related source code in one repo, so would fit the description more accurately.
not really. you can still use monorepo for microservices. since what you want to build based on the path you can mention (mostly) on config.
Can you be more descriptive, how it is it "not really". :)
Hey Patryk,
My personal website uses a monorepo for both the frontend and the backend. The source code is available at github.com/mikenikles/www-mikenikl.... As a follow up, I created a monorepo template at github.com/mikenikles/monorepo-tem....
Each service currently has its own dependencies, so it's not truly a monorepo with shared dependencies across all services. However, I'm writing a book on cloud native web development at the moment and for that, I am updating the monorepo template to include shared dependencies and a CI / CD pipeline that automatically determines which services to build and deploy based on the changes in each git commit.
You can tell, I've had positive experiences with monorepos despite the initial challenges they come with, especially in larger teams. However, with the right attitude, team structures and guidelines in place, I continue to believe the pros outweigh the cons in the monorepo debate.
Do reach out if you have questions.
Don't you think "the right attitude, team structures and guidelines in place" cost too much for most of the companies?
Only a small amount have the problematic like Google of Facebook and require monorepo. From my POV, I've never really used monorepo, but it looks like there is no really consensus on how to manage it, CI/CD are not adapted to it...it cost a lot of time to handle it.
Correct me if I'm wrong, I'll be also happy to get feedbacks of persons who really are using it and can bring clear advantages.
I agree with you, this is a balancing act between cost of maintaining multiple repositories and cost of implementing a monorepo, training the team and putting guidelines in place.
Especially with a lack of best practices and a lack of well documented how-to experiences, this is quite a bit of investment a team or company has to put in.
In my personal experience with monorepos of 15 to 20 engineers who work in it, that initial monorepo setup has been beneficial in the long run. However, I too am interested to hear from others who have hands-on monorepo experience.
Hey Mike,
thanks a lot for your valuable answer. I'll definitely study your template tonight. I wonder what's the way to build a CI/CD pipeline that is suitable for all kind of monorepos, not just JS focused. It seems like monorepos are most popular in JS world with tools like lerna, and even in JS ecosystem you can find various ways to do monorepos (there's no commonly accepted standard).
I can't comment on a multi-language monorepo as I don't have experience with that. My main focus is in the JavaScript ecosystem. This definitely makes the monorepo situation much simpler compared to a multi-language monorepo.
We use the term monorepo, but this was done for transition of on project into two repositories. Management will be very confused if there comes a time we tried to create only one.
We also have a third for the backend and this tends to take on what might be considered another project, like the DB scripts.
Our repos are also forked per client, it is very hard to get all the devs to agree to stay up-to-date and how that actually improves quality even with the risk of breaking something. (QA here trying to build automation, consistent across clients to reduce upgrade failures.)
Is your backend just one application? Or it's a set of micro apps in one repository?
Actually it really is not a mono repo, let me just start over on that one.
Think any plug in platform, like Jenkins. We have the platform, it has its own development team and release.
We then have components which have their own repo. Finally we have the repo which I was talking about. It uses the nuget packages from the components, supplies their configuration and wire up into the platform.
So no not really mono and not really separate applications.
What exactly is a monorepo and what are its advantages?
monorepo only make sense if all sub repositories are in only one language. And I know only one language doing this, JavaScript.
For JavaScript, all modules are shared, that is, only one node_modules folder, ensuring all dependencies' versions are the same.
I'm not sure if it's true that it makes sense only with Javascript, there are huge companies like Google that use it with multiple languages.
But being such a giant as Google allows you to do crazy things.
I'm curious if in small/medium size projects monorepos are popular only in Javascript ecosystem (if we take only small/medium projects into account, then I agree that only JS makes any sense. I think this is the only language that has any tools for doing this anyway?).
I think i can see were you are coming from but,
lets look at some stories to explore this more. :)
Imagine a stack with a C# API server or headless CMS, a couple of FE's intended for different user groups, like end-user or admin.
Add in some machine learning , written in Python that the C# needs to interact with occasionally.
Very quickly, monorepo starts to become the only way, i can think of, that handles these stories. :)
Instead of creating a separate repository for each app, you keep most of your code in one repository.
Pros: all your codebase in one place, you see dependencies across projects, you can make changes across projects etc.
Cons: there is no tooling for managing it easily (IMO) besides maybe Javascript, problems with CI/CD
Currently, I use pseudo-monorepo, not monorepo anymore.
I use no Lerna, no Workspaces, and separate node_modules folders.
Actually, I think we shouldn't use a monorepo for frontend and backend, because browsers' and Node's dependencies can be vastly different. Backend only, or frontend only is OK.