Repository vs Monorepo

[00:00 - 00:24] In this lesson, we will revisit the previous case and we will discuss the differences between standard repositories and the monorepos in details. As you remember, you're the CTO of the company, you will have to create five applications and that applications will have common parts like buttons, like login forms to provide unified look and feel.

[00:25 - 00:43] You have two main options, you can have separated repositories, so you will have five repositories for applications, few of them for common parts, you will probably publish and PM packages to make it work. And the second option is to keep everything in the same repository, which we call monorepo.

[00:44 - 00:55] Let's check how standard bug fixing process looks like when you have that separated repositories. And let's assume that you have a bug in that common components library.

[00:56 - 01:01] First of all, you have to fix the bug, it's obvious. Second of all, you have to have code review.

[01:02 - 01:08] It's a good practice and I wouldn't skip that step. After that, you can merge the code.

[01:09 - 01:21] When the code is merged, you can release a new version of the library, which you can use in your application. So you have to upgrade that library in five applications and then test it.

[01:22 - 01:44] If the code works, you can go to the next steps, but if there's still a problem , let's assume that one of those five applications is not working. You need to go back to the first step, fix it again, you have to merge the code , release a new version of application, upgrade once again, and then you can test it.

[01:45 - 01:57] If you're lucky, after one iteration of these steps, you can release a fixed version of the app. So the biggest disadvantage of this approach is that your dev team will switch context multiple times to get work done.

[01:58 - 02:07] And this causes long time between bug detection and deploy, which is not the best for your clients. You have some advantages of this approach.

[02:08 - 02:22] First of all, your code is strictly separated. So there is no way that someone will create bad connection between some parts of applications. Let's try to check how the same bug fixing process looks like in Monorepa approach.

[02:23 - 02:30] So as previously, fix the bug in the code. There's only one repository, so there is no problem determining where the bug is.

[02:31 - 02:47] After that, because your apps and libraries are in the same repository, you can test the code without publishing any NPM package. If code works, you can go to the next step. If no, you can fix it again and test it again.

[02:48 - 02:57] So you're repeating only two steps. You should notice here that there is no publish step or upgrade library in application step, because it's the same repository.

[02:58 - 03:06] If everything works, you can ask for code review again, don't step this step. It's extremely important.

[03:07 - 03:16] When code is approved, you can merge it into main branch and release a fixed version. As you can see, this list of steps is much shorter in this case.

[03:17 - 03:36] The biggest disadvantage of this approach, of course, is that all code is in the same repository. And if you have a big application, it might be problematic for new developers to find the right file, and it might be problematic if you want to restrict access to some files just for few people.

[03:37 - 03:44] The big advantage is that you avoid time-consuming problems. It reduces context switching, saving a significant amount of time.

[03:45 - 04:02] On the one hand, when all code is in the same repository, it might be problematic and overwhelming for new people. But from the other hand, it's easier to onboard new programmers, because when they ask you, "Okay, where is the code that I need to fix or I need to develop?"

[04:03 - 04:11] It's very easy to point. It's only one repo. To sum up, if you're wondering, what is the biggest advantage of Monterrepa approach?

[04:12 - 04:15] what is the biggest difference is that you save a significant amount of time.