Introduction to the Building Angular applications with NX

Speaker introduction and course overview

What is NX?

Difference between Repository and Monorepo

Repository vs Monorepo

Angular and NX - Why?

Advantages of NX

Disadvantages of NX

First module summary

Introduction

Second module introduction

Short lesson about NX installation methods

NX installation

A quick overview of the default suggested directory structure of NX repository.

NX repository folder layout

Second module summary

How to install NX

How to build a simple application and how to create libraries in NX

Third module introduction

Adding the first app

Adding the first library

Code session for the first application and library in NX.

Time tracker code

Third module summary

The first NX Angular application

What else you can keep in monorepo...? Multiple apps using multiple frameworks, built-in Storybook and Cypress configuration

Fourth module introduction

How can you add more apps to monorepo, which frameworks are available at the time, and advantages of keeping them together

Built-in app types in NX

What are buildable and publishable libraries

Built-in library types in NX

Storybook

End-to-end testing

Fourth module summary

More built-in NX features

This module will present a real-life example of an NX mono repository with multiple libraries and three applications.

Fifth module introduction

Presenting the current module's plan, highlighting crucial backend details for the frontend to illustrate the problem domain.

Backend overview

How to migrate simple existing applications to NX

Migrating backend app to NX

How to extract library with DTOs classes from backend app and prepare it to be shared with frontend application

Extracting shared DTO library

Let's look at how our final application should look like

Design overview

Add new Angular apps to the existing NX repository

Adding new Angular apps to existing monorepo

Adding Storybook to monorepo - different approach

Using previously configured Storybook in this lesson we will create and prepare a few common components that later we’ll use in apps.

Adding common components. Card, Button, Input, List, ListItem

Adding a domain library for RoomList, RoomBackground and RoomTimelineList that I missed in previous lessons

Constructing the services of the application

Constructing the application - Services

Constructing the Admin application

Constructing the Room application

How to prepare the application to work offline

Preparing the Room applications to work offline

Summary of building a real-life application with NX

Lessons learned and homework

Building a real life application with NX

Sixth module introduction

What is the dependency graph in NX, and how does it help you with developer experience

Dependency graph - what is it?

Why it’s important to keep the dependencies organized

Importance of keeping dependencies in order

How to run unit tests and lint only on the affected parts of the dependency graph

Affected

How to deal with the most common examples of circular dependencies

Dealing with circular dependencies

Sixth module summary

Dependency graph

Seventh module introduction

How to automatically migrate simple applications to the NX mono repository

Automatic migration of existing applications

How to manually migrate complex applications to the NX mono repository

Manual migration of existing applications

What may be the problem during migration of big, stale existing codebases

Analysis of potential problems in migration of big existing codebases

Tips. The migration plan

Why defining a target architecture may be an important step of the migration process

Tips. Target architecture

Seventh module summary

Migrating existing applications to NX

What you have learned from this course

Contact info and final words from the author

Final words

Summary

### Challenges and solutions in building large Angular apps

In large Angular applications, developers face several significant challenges. One major issue is managing complexity. These apps have lots of components, services, and modules that all need to work together smoothly. Keeping everything organized and easy to understand can be tough, especially with a big team.

Another problem is build times. As the app grows, it can take longer and longer for changes to show up during development. This can slow down the development process and make it harder to stay productive.

Dependency management is another headache. This involves making sure all the different parts of the app work well together and play nicely with outside libraries. 

### Tool limitations

Even experienced teams can struggle with managing large Angular applications without using the right tools. Organizing numerous components, services, and modules becomes challenging without tools that aid in clarity and team collaboration. Utilizing appropriate tools is key for experienced teams to successfully navigate the complexities of large Angular projects.

### Fixing problems with NX

NX offers several benefits for managing large Angular applications. It helps reduce the time it takes to build projects and keeps code well-organized by managing dependencies and structuring code into reusable parts. This makes it easier to maintain and expand applications over time.

One of NX's strengths is its ability to speed up builds. It does this by remembering previous build results and doing multiple tasks at the same time. This saves developers time and lets them make changes quickly.

NX also comes with tools for testing and checking code quality. It works well with common testing tools and helps keep code clean and consistent. This catches mistakes early and ensures code stays high-quality.

Furthermore, NX makes it easy to work together on projects. It keeps all code and shared parts in one place, making it simpler to share code between different projects or teams. This improves teamwork, reduces problems with combining code, and makes development smoother overall.

Manage Large Angular Apps and Supercharge Development Workflows

Learn how to create and maintain Angular applications using NX. 
Designed for Angular developers, this course covers best practices, improving workflow, and migrating existing applications to NX. 
Discover how to configure tools like Cypress for end-to-end testing and Storybook for UI component development. 
By the end of this course, you will have the knowledge and experience to work comfortably with NX on a daily basis.

Next-Level Angular Apps with NX

Build a simple time tracker application using NX monorepo.

Create a real-life NX monorepo with three applications. The main goal of these applications is to display the schedule for conference rooms on screens mounted to the doors of the respective rooms.

Build an admin panel as one of the applications to manage the schedule data for the conference rooms.

Use NX graph feature to visualize application architecture.

What is a monorepo approach and how it might help you

Differences between Angular CLI projects and NX projects

How to create Angular applications using NX

How to add Cypress and Storybook to your NX monorepo

How to migrate existing Angular applications to NX monorepo

What is a dependency graph and how to use it to save your time

How to prepare migration even for big and complicated projects

In this lesson, I'll describe the most problematic migration parts for a few popular application types.
As we said in the previous lesson, every application is unique,
and has problems that may not happen during other migrations.

Happily, we can predict some common problems if we categorize applications well.
I'm going to split applications by size and organization structure.

It's very important that some problems you may need to address will not be strictly connected to the code.


Organizational structure,
number and size of teams, or even how application parts are assigned to teams all these factors may be important.
Some of your decisions may be based on it and equally on the code.

This lesson is focusing on the following cases:

You may remember similar cases from the lesson about the importance of keeping dependencies in order from the previous module.
Keep in mind
that some problems may be avoided, and the migration process may be easier
if your application does not contain problematic dependencies.

The biggest problem during the migration of huge applications is, of course, the code.


The worst part of this case is that all your coworkers work on the same code.
So the whole company will face the same issues if something goes wrong.

It may sound silly, but it's easier when big applications are maintained by a small team it's easier to do the migration.
As a team, you work with each other every day.
This fact helps to solve issues that may happen during migration.
Work and tasks can be easily distributed.

It's very unlikely that all teams will take part during migration.
This means that one team has to block development for some time, and other teams will be forced to wait.
This also means that only one team will have a very deep understanding of the process.
To sum up, when you have a huge application with a few hundred thousand LOC,
and multiple fronted teams maintain it
(let's face it: you need a bigger team or multiple teams to maintain an application of that size efficiently)

the main problem may be the coordination and communication between the teams.

---
title: Analysis of potential problems in migration of big existing codebases
description: What may be the problem during migration of big, stale existing codebases
privateVideoUrl: https://stream.mux.com/HGywcY2nm1TEHev2ozx5zuY9uKvpl01VkVp0065r5mah8.m3u8
---

In this lesson, I'll describe the most problematic migration parts for a few popular application types.
As we said in the previous lesson, every application is unique,
and has problems that may not happen during other migrations.

Happily, we can predict some common problems if we categorize applications well.
I'm going to split applications by size and organization structure.
**It's very important that some problems you may need to address will not be strictly connected to the code.**
Organizational structure,
number and size of teams, or even how application parts are assigned to teams all these factors may be important.
Some of your decisions may be based on it and equally on the code.

This lesson is focusing on the following cases:

-   One huge application

    -   One small team
    -   Multiple teams
-   Multiple small applications

    -   One small team
    -   Multiple teams
-   Multiple big applications

    -   One small team
    -   Multiple teams
-   One small application

    -   One small team

You may remember similar cases from the lesson about the importance of keeping dependencies in order from the previous module.
Keep in mind
that some problems may be avoided, and the migration process may be easier
if your application does not contain problematic dependencies.

## One huge application

**The biggest problem during the migration of huge applications is, of course, the code.**
The worst part of this case is that all your coworkers work on the same code.
So the whole company will face the same issues if something goes wrong.

### One small team

It may sound silly, but it's easier when big applications are maintained by a small team it's easier to do the migration.
As a team, you work with each other every day.
This fact helps to solve issues that may happen during migration.
Work and tasks can be easily distributed.

galczo5

In this lesson, I'll describe the most problematic migration parts for a few

As we said in previous lesson, every application is unique and has problems

that might not happen during other migrations.

We can predict some common problems if we categorize applications well.

I'm going to split applications by size and organization structure, so number

and size of teams that work on that application.

You may remember similar lesson from previous module.

I want to remind you some problems that you may have during migration.

Then we will focus how to prepare a migration plan for each of these problems.

So first case when you have one huge application.

And of course the biggest problem during the migration is the size of

It's just huge, there's a lot of code and you have to migrate it.

The worst part of this case is that all your co-workers work on the same code.

So the whole company will face the same issues if something goes wrong.

What's more, migration process will be blocking for the whole company.

So when that huge app is maintained by one small team, it's easier to migrate

As a team you work with each other every day.

And this fact helps to solve issues that may happen during migration.

And when you have one small team work and tasks can be easily distributed.

It's a bit more complicated when you have multiple teams that maintain that

So it's very unlikely that all teams will take part during migration.

This means that one team has to block development for some time and other teams

And it means that only small part of organization will have a very deep

understanding of the immigration process.

To sum up, when you have a huge application, the main problem you may have is

coordination and communication between teams.

And my advice here is to focus on that coordination and communication between

The second case, when you have multiple small applications, the biggest problem

Because applications are not too big, it should be quite easy to migrate them.

But the problem may happen when you start extracting libraries.

So if you extract one library and then you want to reuse in other applications,

And you have to introduce change in all of them.

When that multiple small applications are maintained by one small team, the

And during the migration, they cannot do anything else.

So it's a problem for the whole organization that your team, the only one team,

spends time migrating existing applications

instead of coding features and fixing bugs.

This time, of course, should be considered as maintenance and it will boost the

When you have multiple teams and multiple small applications, it's a bit easier

The only problem is to start the migration to migrate the first application.

Then you can distribute work between teams.

And again, the biggest problem will be communication and coordination between

So you probably noticed, come on part, when you have one huge application or

when you have multiple teams, you always have to deal with communication and

And it's very, very important because if you don't know how to coordinate teams

some teams will be blocked during migration.

When you have multiple big applications, as you may expect, this case is

similar to the case of multiple small applications.

The difference between multiple big applications and multiple small

applications is that every action will take more time to execute.

Every issue, every back, everything will take more time to resolve.

And I believe that everyone knows that this kind of migration is not a piece of

It's pretty complex operation to do and it's way better to be well prepared.

No matter if your organization is built by one or multiple teams, you will have

Sometimes you cannot solve complex problems with simple solutions.

So my advice here is to focus on preparation.

So when you have one small application, I don't see any problem.

So no matter if you have one small team or multiple teams, small applications

You can even use that automatic migration from previous lesson and it's done.

And you don't need to spend time on migrating it.

The main goal of this lesson was to inform you to remind you about the problems

It's important to know what may happen because it lets you prepare for the

And no matter if you have one huge application or multiple small applications,

you will have some problems and it's easier to deal with them if you have some

ideas what may be wrong with migration process.

In the next lesson, we will focus on preparing the migration plan.

It's often skipped stage, but if you go with it, it will help you in long and