I will sound like I'm repeating myself. Still, it's important to understand that the main advantage of NX is that it helps you to keep everything in order.
No matter if we talk about applications or libraries.
There are a few cases worth discussing, and each has its own problems.
In this lesson, we'll focus on these cases.
I'll try to describe them and what may be the most problematic during migration.

Before we start, please remember that every case is unique,
and you should always consider other ways of solving things.


When you know different cases, it's easier to make a good decision, and with those words, let's move on.

One huge application, multiple small teams

Let's start this case with an important fact: huge applications are often developed for a long time.
It's good when all existing code is well documented, but based on my experience, it's unlikely.
Usually, developers migrate,
so you will have code created by developers no longer working in the company.
Even if they are still available, the code may be so old that no one remembers how it works.

The next problem you'll approach is tightly coupled code, which shouldn't be tight.
Code coupling is describing how independent are parts of the code.
Simply put, a tight-coupled code will have a lot of dependencies, and it's hard to refactor.
When you want to change one thing, you need to refactor other parts of applications as well.
Code like that is often created when developers try to cut corners and have strict deadlines.

We'll discuss a migration plan for this case in the next module.

Multiple small applications, one small team

When you have a lot of small applications and there are no shared parts,
it may be problematic to maintain one small team.
Introducing NX may not help at first.
It's sad to say,
but NX is not a magic wand, and if the team often has to switch contexts and there are no shared parts,

You can still spend some precious time and introduce NX,
it will help you because all applications will be in the same repository,
so it's easier to switch contexts,
pull new changes, etc.

I would consider having some parts common for all applications.


Time invested in this will pay you off later.

But buttons in these applications have to look different!


Ok, what about creating a component that is separated from styles,
so you have a common code for buttons, and you apply different styles on each application?
There's always a chance to create shared libraries and save time.

Multiple big applications, no shared parts, multiple teams

A situation like this is often created when bigger groups acquire companies.
Sometimes, these applications have nothing in common. Even the technology stack may be different.

---
title: Importance of keeping dependencies in order
description: Why it’s important to keep the dependencies organized
privateVideoUrl: https://stream.mux.com/AntUnFNR1b01vFHE02U2g7d8EQFaQXR63QvhnU9IG02Hy8.m3u8
---

I will sound like I'm repeating myself. Still, it's important to understand that the main advantage of NX is that it helps you to keep everything in order.
No matter if we talk about applications or libraries.
There are a few cases worth discussing, and each has its own problems.
In this lesson, we'll focus on these cases.
I'll try to describe them and what may be the most problematic during migration.

:::note

**Before we start, please remember that every case is unique,
and you should always consider other ways of solving things.**
When you know different cases, it's easier to make a good decision, and with those words, let's move on.

:::

### One huge application, multiple small teams

Let's start this case with an important fact: huge applications are often developed for a long time.
It's good when all existing code is well documented, but based on my experience, it's unlikely.
Usually, developers migrate,
so you will have code created by developers no longer working in the company.
Even if they are still available, the code may be so old that no one remembers how it works.

The next problem you'll approach is tightly coupled code, which shouldn't be tight.
Code coupling is describing how independent are parts of the code.
Simply put, a tight-coupled code will have a lot of dependencies, and it's hard to refactor.
When you want to change one thing, you need to refactor other parts of applications as well.
Code like that is often created when developers try to cut corners and have strict deadlines.

![Code coupling](https://d2uusema5elisf.cloudfront.net/courses/building-angular-applications-with-nx/module_06/lesson_06.03/public/images/05-03-01.png)

We'll discuss a migration plan for this case in the next module.

### Multiple small applications, one small team

When you have a lot of small applications and there are no shared parts,
it may be problematic to maintain one small team.
Introducing NX may not help at first.
It's sad to say,
but NX is not a magic wand, and if the team often has to switch contexts and there are no shared parts,
**the problem is not technical.**

You can still spend some precious time and introduce NX,
it will help you because all applications will be in the same repository,
so it's easier to switch contexts,
pull new changes, etc.

galczo5

Why it’s important to keep the dependencies organized

Importance of keeping dependencies in order

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.

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.

Small disclaimer, before we start, please remember that every case is unique.

And you should always consider other ways of solving things.

NX is not a wonderful solution that fits every case.

And you are the person who understands your case the best.

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.

So let's start with first case, so one huge application that is developed by

First fact that it's important, huge applications are often developed for a

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

it's unlikely that you will have documentation.

What's more developers who wrote that code migrated to other companies, so you

"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

It's natural when you have a huge application that was developed for a very

that you will have some dependencies, some connections that are unnecessary,

And you should know that it's way easier to split the application into

libraries when the code is loosely coupled.

So when you have that tight coupled code, it might be a problem.

And introducing NX might not be that easy.

What's more, these connections are very often created by developers, just to

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.

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

If you have multiple applications that share no parts with each other and you

I don't think that NX is going to help you.

The problem is not technical. The problem is in organization.

Even if you introduce NX, your developers will need to switch context multiple

I would consider having some parts common for applications.

Time invested in this will pay you off later.

For example, you can have shared buttons, forms, and so on, so you don't need

You don't need to fix the same problems multiple times.

And even problems like styling, for example, all these applications look

These things might be solved in generic way.

So to sum up, when you have multiple small applications developed by one small

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

And this situation is very often when the company acquires another company.

They have different code, different code stack, even different technologies or

So because company is built by two or multiple major organizations,

you can consider if applications should have shared parts or should not have

If applications should have shared parts and you want to introduce them,

The biggest problem you may have is how to migrate, how to create these shared

and then introduce it to the applications.

And in this case, when the applications shouldn't have shared parts.

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

and rethinking introducing these shared paths.

The case, multiple big applications developed by multiple teams.

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.

So introducing some shared parts to applications and the migration plan.

And the biggest advantage of NX migration in these cases is maintenance.

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.

In addition, developers can change teams easily because they have access to the

And for organization, it's way easier to let people switch between projects

The last case is when you have one small application that is developed by small

I would probably not suggest introducing NX to this case.

It's another layer, it's a complication, you will spend your time introducing

but I see some cases where NX may be beneficial.

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

Masterclasses

Tutorials

Fullstack React with TypeScript