Monorepos Done Right: Scaling Codebases Without Losing Your Mind

Thank you. That was a nice introduction. I got some marketing for myself as well. Eight plus years of experience, wow, like focused on component testing, accessibility, UA scalability, whatnot in the front end. I work at EZ GO and then, yeah, we are like one of the Australian powerhouse behind the most popular online casino.

And then we do own couple of products, Steak and Kick, if you've not seen them or used them before, feel free to. Well, what's a monorepo? Yes, I'm a simple person. I did see slides with lot of, like, effort put into it, but then, like, come on, let's be honest, like, who would prepare a presentation without some memes in it?

So, yeah, I do have a lot of memes, and then I'm using a lot of analogies, but please bear with me with the presentation. So, let's start with, like, a simple idea, right? Like, let's think of a massive library, not just with novels, but, like, a single place where you have like encyclopedias, research journals, and all other categories, it's under like one roof.

If you bring the same concept or like the same analogy into like the software world, that's what is like MonaRepo, right? And then I keep people often getting confused between microservices, like front micro frontends or like MonoRepo. I think like there is a little bit of difference in concept. They're microservices and micro frontends are like architecture based, right?

They are like to give an architecture to your code. Whereas, like, Monorup is not architecture. It's just like segregating your code properly. It necessarily need not be architecture, right? Like, it's just a huge repository, whereas like a single source control repository that holds the code for like multiple projects. Whether they're related or not, that's fine, right?

Like, unlike the traditional multi repo approach, where like each project lives in its own like separate repository, whereas Mona repo brings all of them together into one unified place. Now, who on real world would want to bring and put all of them into one single place, right? That's why I want to take some examples of the companies that have been using these monorepos.

Like Google's code base is one of the huge code bases that's known to humankind, and then they back it using their Piper, which is like a build tool. Same as like Facebook, the back it based on like Mercurial and then like Buck which is like also their deployment tool. And micro service like how many people are using micro service laptops.

All of the micro service like code bases behind and Uber, Airbnb and Atlassian, which we just heard and then of course, Kohl's. So, what's a poly repo? I don't think I have to talk much about like poly repo, right? Poly repo is just one single repository independent of each project.

Like one project in one single repository, and then each project lives at different place. And then every project has its own rules, has its own ways of doing things, has its own UI, has its own back end and whatnot. So why specifically like I'm talking about like MonoReport, like why should we change our code base to MonoRepo?

Why should we, like, start the code base with MonoRepo? So, like, let's be honest, like, managing code across, like, multiple teams and projects can sometimes feel like a bit too much, right? Like, now imagine, like, if everybody could just, like, work under one roof, following the same playbook and then stay in sync. That's kind of like the superpower MonoRepo offers.

And yeah, like centralized dependency management. In MonoRepo, all the projects share single source of truth for dependencies. No wonder which version of library used or dealing with version mismatches. Or if you update, let's say, single UI library or a UI component or a helper function, then it's reflected everywhere, right?

And one single commit, and then it minimizes the code duplication, reduces bugs, and then kind of try to keep things tidy, but that's subjective. We'll get to that in the later slides. Easier code sharing refactoring kind of go hand in hand, like code reuse becomes a breeze, teams do not have to like publish internal packages or like even do not have to like wait for like the version bumps or like worry about syncing changes.

You can just simply like import the shared modules and then get going. This kind of like accelerates development, especially when multiple products or like services needs to use the same core logic. And the next thing, atomic commits across projects. Have you ever, like, fixed a bug that has to be fixed across, like, multiple repositories?

Imagine, like, the same fix has to be done in, like, places, and then, obviously, you need to make sure, like, they're all in sync to get the things going. That's kind of things that MonaRipa solves, like one commit, boom, and then, like, it fixes the issue. This means, like, more cleaner, like, history, like safer releases, fewer broken bills, and also, like, better visibility across teams.

I've often seen, like, projects where the user management would be in a different repository, the payment gateway would be in a different repository, and then every functionality would sit at a different repository. And then, like, teams working on it would not have visibility of, like, the other side of the things. Whereas in MonoReport, like, everything sits at one place, right?

Like, one person working on a single thing has, like, context across, like, all of the other projects, And then he kind of like has the leverage to like go and fix something that's beyond what he's doing. And then it's not just like fixing, but also like a learning, right? Like, consistent CICD pipelines. I mean, like, when everything is one place, your continuous CICD or delivery pipelines can be standardized.

You don't need to, like, have a dozen setups for, like, each repo. Or, yeah, like, this means, like, more predictable deployments, easier onboarding of people and better developer experience. So before jumping into the game of like why, like what's the difference between MonoRepo and PolyRepo, let's get going with I like kind of try to like set up a monorepo from scratch and then like show you guys like the idea of like what do I mean by a monorepo.

If people who've never seen monorepo before, like how does MonaRepo be structured? I just want to like show the things. It's simple. Let's go to

MonaRepo presentation.

It's visible, right? Yeah, it's visible. So, well, Monorepo can be done with multiple tools.

There are like so many tools available on the market to get up to scratch with Monorepo, but let's stick to basics for now. Of course, like Monorepo has multiple projects and then you have like multiple versions that you need to manage. So there are like tools like YARN that help you with like management and then like PnPM does also help you with the version management. Today, I'd be using PnPM just because like both Yarn and PnPM has like two different like ways of dealing things.

Whereas Yarn helps you with like much complex projects. It'll have like better code coverage, whereas like PNPM often like concentrates on disk spacing and then like faster efficiency. So since like we're just like putting something up from scratch, we'll just you make use of MonoPNPM And then so just like init creates like a package.

Json for us and then like versioning. I'll talk a little bit more about like versioning later, but that's also one of the reasons of using Monorepo. Let's say we can do like pnpm create me. Create with weight. Using wheat build tool, I'm just creating a project called website and then let's so Svelte is something that we use at EZ Go, so that's why I chose to go with Svelte and then see it created a website for us and then it has like a package.

Json. Let's go back to So this is kind of like the PnPM docs that I've been like using. So to create a workspace, you can just like use this reference from the YAML and then like literally copy paste this template to start with.

So instead of my app, that will be the website that we've created. And here we can kind of create a folder called packages and then let's let's keep it simple and then we can go with like a folder called utils that we can be shared across like the other projects as well.

And then if you do like a you can like just go do PMPM in it at like the root level.

Let's see what's going on there.

Okay. In the package of JSON, have like a build p n p m run dev. That's your app like basically. Well, like the live demo gods are not with me today, I guess.

Okay. There you go.

I've just installed the app and then if you see it created like a package dot log json on like the root level folder and then obviously from the that's the reason I put it to the YAML it like there. Move the YAML back to the root level folder and do a p n p m install.

Yep. Now, if you check the log file, it created like a dependency for your app, the website, and then like a dependency for your packages. And like literally you can add like instead of utils, can add like a new folder called UI and then have all of your like buttons inside like the packages and then your utils and then you can have as many as reusable things in your code base. And then instead of like one single website, you can be like multiple folders like you can create a thing called apps and then move your website to the apps.

Move all of your website to the apps and then like have multiple apps with like packages sitting with each other. So, I think we that's all. Yeah. We have like packages whereas like your UI components, utils, and then we have like apps, website, and then we can have like multiple apps inside. And then this is kind of like the MonaRepo architecture like that would be once like defined properly.

But let's jump back to like the presentation. So, like, this is just like I'm trying to, like, I've tried to, like, compare what's like a MonoReport and a PolyReport. If you see, it's just like a code organization, like, when it comes to, like, code sharing, it's, like, easy and convenient, whereas it requests external packages for poly report.

It's nothing to do with architecture or like anything to do with micro service or like micro frontends. Like, literally, if you have like a micro service back end, and then you have like a micro frontend, all of them can live in your MonoReport. Like, it's both are like two different concepts altogether. And then CICD management, like we've discussed, like, can have like one single centralized management for like MonoReport, whereas like for PolarReport, like every repo has to have like its own CICD built in collaboration, like the same we've talked about high visibility.

Teams often need to go through multiple things. Autonomy, like less because in Polaripo, people can just go and then do whatever they want, see how other apps work and then try to connect the dots. Whereas, like, in Polaripo, they need to go through a lot of talk to many people, like go through a lot of knowledge transfers and all these things.

And versioning, there are like so many tools that help Monorepo, which does the versions for your releases. So that way, all of your history is really clean. You can move from one version to another. And then there are specific MonoRepo tools that concentrate on versioning, which we'll talk a little bit later in the presentation.

But then, like whereas for PolyRepo, you're only versioning that particular concept of the repository. And then maybe that the other repositories might be at a different version and then your repository might be at a different version. There's always like this mismatch and then like, un sync between the projects. And then onboarding, obviously, like, it's easy for like people to like know what's what's all in like they're going to work with. Whereas in PolyReport, there's like a steep learning curve.

Like, every time they move project, they need to start everything from scratch, like trying to understand the project. Well, we've talked about everything, right? Like, say, hey, MonoRepo is really good, this is why you should use it. It's a breeze and all these things, but it's really important to know when not to use a MonoRepo. I've gave examples of saying like, hey, Google's using it, Facebook, Atlassian, and Valve, like the top companies have been using it.

So the success for like being a top company's monorepo, like definitely no. And then it's not that simple as well. Often, when you start, we'll like I build a project from scratch, and then I was able to, like, say, hey, this is my packages, this is my UI components, wow, very clean. But then, often with MonoReport, you end up in a situation where you have your PolyReport for, like, working for some time, and then all of a sudden, you're like, oh, shit, like, I should have used Monorep to solve my problem?

Or you start your journey with Monorep, and all of a sudden you feel like, no, shit, I should move to PolyReport to solve my problem. That's like the 90% of the time where you end up with. So it's not as easy as I say. I tried to bring some points to say when not to use, but these are not limited, really.

Obviously, when you start your project, if you want to have very separate teams, you don't want your user team to know your payment, what the payment team is doing, or you don't want your payment team to know what your KYC team is doing, like, obviously, like, Monorip is like a no brainer. So minimal need for code sharing.

If all of your code is like independent of each other, and then there is like no necessary of like syncing the versions or like keeping all of them in sync, then, yeah, I don't think MonoRip is like a really good choice for you. Also, like, it's a team strongly prefer independent work follows that changes from individual to individual and security and access control.

Obviously, like, also related to projects unrelated around it comes under, like, the same roof. Well, I've been talking about, like, when not to use, why to use, but then, obviously, like, I should not get away from saying like what are the downsides of MonoRepo. Obviously, like, in the previous presentation, we've heard like people suffering with problems with like MonoRepo, like getting the bundling sizes incorrect, And then sometimes like the CICD pipelines, it's a nightmare.

So if you don't think of it like properly and then like get your things right before like migrating to a MonoRepo, it's actually going to increase your pain of dealing with the code base. Like, let's say, if you have an existing project, and then you have 10 developers actively contributing to your poly repo, and then you want to migrate your poly repo to a monorepo.

Like, imagine every day you have ten, fifteen commits going into the master, but then you change your code structure from your components going to the packages and then your apps, and then you keep creating the new app. Every time they make a change, they somehow need to rewrite the whole change to your new updated structure, or you kind of have to create a script that updates the code to your different structure that you've migrated.

And also, like, keep in mind that, like, git history plays a crucial part. You just don't want to lose all of your git history on your code as well. So it's not like visually, like, very easy, like, migrating existing FOLI repos. And, of course, like, risk of performance bottlenecks in large repos. Like, we've seen of it before, people are trying to fix the performance bottlenecks. Like, of the times, you'll be dealing with things that you wouldn't be dealing with if you're in a poly repo kind of setup. And then complex CICD if not planned well.

Like CICD, yes, it will be centralized, then, like, imagine if it's not planned well. You have, like, two different CICD structures in a poly repo, and all of a sudden you come to a monorepo trying to synchronize your CICD, it will, like, go really bad as well. And of course, like steep learning curve. Now, if you have like one more thing on top of your code base, instead of just knowing about your code base, now you have to like learn about NX, what's Basil, and then like all of the other tools that are available.

And then, obviously, like when you have like large code ownership, like when there are like large code and then multiple people trying to like save, make changes to the same code, we have like merge conflicts that we need to deal with as well. Like, if you see like, if you're not doing it properly, then you kind of like end up like being in a situation where you don't want yourself to be in and, yeah, of course, like, you need to like make sure that testing is spot on.

If not, you often break like many things. Well, this is the tooling that I've been talking about. Like, these are like the tools that kind of existed in the market, like PNPM which we worked with package manager just in the demo, and then we've discussed about YARN. TurboRepo is like often like the choice of like people because like it concentrates on faster builds, remote caching and it's ideal for JSTS front ends. Whereas, like, I in my personal opinion, I feel like NX is like the complete setup of Monorepo.

It tries to find a balance between everything, whereas TurboReport just concentrates on speed, whereas like NX gives you like that complete picture of like what a MonoRepo is. Rush is a tool that Microsoft has been using and then that often helps with like larger code bases where it does a very good job in versioning and change detection.

So Microsoft backs it because it works well for them. But unlike like in the demo where we saw like we have to like create so many folders and then we have to like emit them, we have to like do everything. If in a real world, if you're using NX, all you need to do is like, create So this is like one simple command that you would use.

Can you see my screen?

So this is kind of like one single command that NX does and then like you do this command it's going to be like the exact same structure. You're gonna have apps, you're gonna have everything like pre configured. So to like bring something up from scratch for like using an NX tool, it often takes like a minute or so.

That's how powerful they are. And then they also have like good extensions in Versus Code when you're like experimenting with NX. Do make sure like you install the NX console package that's like kind of powerful, like helps you with the console commands. But like I said, obviously, there's like a learning curve that you need to go through to understand how NX works.

So my final thoughts, whatever I spoke doesn't make sense to people, that's fine, like you're not alone. It's not like as simple as you understand like what monorepo is, when to use or like when not to use. But it works well if you invest early in the tooling and then also it sets like if you have like a clear ownership boundaries, testing strategies and CICD pipelines, then it works really well.

It isn't easy, but with the right approach, it's actually absolutely worth it. That's it from my end for today.