Importance of keeping dependencies in order

[00:00 - 00:10] It's very important to understand that the main advantage of NX is that it helps you to keep everything in the order. No matter if we talk about applications or libraries.

[00:11 - 00:22] So let's focus about different cases you may approach during using NX. Let's consider when NX is helpful and when NX is unnecessary complication.

[00:23 - 00:31] Small disclaimer, before we start, please remember that every case is unique. And you should always consider other ways of solving things.

[00:32 - 00:39] NX is not a wonderful solution that fits every case. And you are the person who understands your case the best.

[00:40 - 00:50] So I want to show you different cases to make it easier to make a good decision . But please use these cases as a knowledge that helps you not a recipe.

[00:51 - 01:02] So let's start with first case, so one huge application that is developed by multiple teams. First fact that it's important, huge applications are often developed for a long time.

[01:03 - 01:15] So you will deal with old code, you will deal with a lot of technical depth. And it's very good when you have documentation to the code, but based on my experience, it's unlikely that you will have documentation.

[01:16 - 01:34] What's more developers who wrote that code migrated to other companies, so you will have no person to ask, "Okay, what this code is doing, how to maintain it," and so on. The next problem you probably will approach in huge applications is tightly calculated code.

[01:35 - 01:51] It's natural when you have a huge application that was developed for a very long time, that you will have some dependencies, some connections that are unnecessary, that are only complicated things. And you should know that it's way easier to split the application into libraries when the code is loosely coupled.

[01:52 - 01:58] So when you have that tight coupled code, it might be a problem. And introducing NX might not be that easy.

[01:59 - 02:18] What's more, these connections are very often created by developers, just to meet with deadlines, just to deliver that they promised to deliver at the end of Spring. So the main problems, first of all, is that code might be old, tightly coupled, and you don't have any documentation or even developers who wrote that code.

[02:19 - 02:29] And we'll discuss a migration plan for this case in the next module. The next case is when you have multiple small applications that are maintained by a small team.

[02:30 - 02:41] So I see two cases here. If you have multiple applications that share no parts with each other and you have only one small team, I don't think that NX is going to help you.

[02:42 - 02:49] The problem is not technical. The problem is in organization. Even if you introduce NX, your developers will need to switch context multiple times.

[02:50 - 02:56] I would consider having some parts common for applications. Time invested in this will pay you off later.

[02:57 - 03:04] For example, you can have shared buttons, forms, and so on, so you don't need to repeat the code. You don't need to fix the same problems multiple times.

[03:05 - 03:13] And even problems like styling, for example, all these applications look completely different. These things might be solved in generic way.

[03:14 - 03:37] So to sum up, when you have multiple small applications developed by one small team, it might not be a technical problem, it might be a problem in organization, and introducing NX without having some shared parts might be not the best idea. The next case, so we have multiple big applications with no shared paths developed by multiple teams.

[03:38 - 03:47] And this situation is very often when the company acquires another company. They have different code, different code stack, even different technologies or frameworks.

[03:48 - 04:01] And I see two subcases. So because company is built by two or multiple major organizations, you can consider if applications should have shared parts or should not have shared parts.

[04:02 - 04:09] If applications should have shared parts and you want to introduce them, of course, NX will help you. It's a useful tool in this case.

[04:10 - 04:21] The biggest problem you may have is how to migrate, how to create these shared parts and then introduce it to the applications. And in this case, when the applications shouldn't have shared parts.

[04:22 - 04:39] In this case, similar to small applications maintained by one team, I would suggest rethinking if there is a sense of introducing NX or maybe you should really consider and rethinking introducing these shared paths. The case, multiple big applications developed by multiple teams.

[04:40 - 04:48] They probably shared some parts and NX here is a natural choice. The problems you will have are pretty the same as in the previous case.

[04:49 - 04:59] So introducing some shared parts to applications and the migration plan. And the biggest advantage of NX migration in these cases is maintenance.

[05:00 - 05:12] You will save a lot of time by maintaining the shared code only once, not multiple times, not three, four times and so on. When you keep everything in one monorepo, it's way easier.

[05:13 - 05:20] It's in the same place. In addition, developers can change teams easily because they have access to the code.

[05:21 - 05:28] They can check what is inside. And for organization, it's way easier to let people switch between projects than losing developers.

[05:29 - 05:38] The last case is when you have one small application that is developed by small team. I would probably not suggest introducing NX to this case.

[05:39 - 05:59] It's another layer, it's a complication, you will spend your time introducing it, but I see some cases where NX may be beneficial. For example, if your company is growing fast and you don't know how fast your app is growing, introducing NX at very early stage make your code more organized and easier to grow.

[06:00 - 06:09] In that case, you can spend some time at the beginning with when it's easy and then have a lot easier work. You may need clarification about this lesson.

[06:10 - 06:22] So we should speak about the importance of keeping dependencies organized. And I'm describing to you some situations, companies and organizations and how problematic it may be to introduce NX.

[06:23 - 06:33] I mentioned many problems which may be avoided by well organized code, so don't get me wrong. NX is not the ultimate practice that will solve all problems.

[06:34 - 06:46] It will be helpful if you decide using NX and it makes your code better, but not in all cases. What's more, using NX will not automatically mean that your application is good .

[06:47 - 07:05] Tools like NX and XGraph are very helpful to keep your dependencies in order. And we'll be back to these cases in the next module when we will discuss different migration strategies and how to prepare the plan for migration and the composing applications into libraries.