The complete guide to designing, developing, testing, and deploying enterprise applications with Angular

Angular Applications Architecture

Requirements and FAQs

Code style guide

Introduction

Start from the domain

Software architecture for Front-end

Domain, design, develop

Workspaces scenarios

Applications and Libraries

Mono repository multi project

Domain boundary with plain TypeScript

Application details with Angular

Presentational details with Angular

Domain boundary and application details

Testing big Angular solutions with ease

Narrow tests for business logic

Visual tests for the presentation layer

Wide tests for the user experience

Testing since the beginning

Configuration environment and tokens

Instrumentation measuring and logging

Security authentication and authorization

Core generic infrastructure

A library for your shared UI vocabulary

A set of basic atomic elements

Some generic composed blocks

User interface, a design system foundation

Reactive stores with Signals

API access as a commodity

Interceptors for the dirty job

Data stores, reactive access, and persistence

Features come in routes to pages

Anatomy of a Page control flow and services

Different levels of state management

Routes and pages

In this course we teach you how to design, develop, ane deploy enterprise level Angular Applications the right way. Despite the fact that Angular is an opinionated framework, specially suited to build large solutions, it requires a deep knowledge to take decisions at every step.

In almost 30 lessons we cover how to choose and use the correct tools, how to structure an application that scales and how to code some intricate solutions to common problems. It's a long course/book and comes with a complete working codebase fully tested.

It is taught by Alberto Basalo who has been working, advising, and training multinational corporations, banks, and public administrations in Angular for years.

The complete guide to design, develop, test, and deploy enterprise applications with Angular

How to design, develop and deploy big enterprise applications with Angular.

Best practices to organize your code in small reusable libraries.

Application of reactive flow patterns for better user and developer speed.

Leverage the latest Angular version features like stand-alone components.

Common functionality for any application ready to use.

 and learn how to build a suitable scaffold for our project. Then, we will discuss deeper options to group Angular code and learn how to choose the best grouping option for each case.

 is just a demo application, not a marketable project. But I want to use it to teach you how to build a significant, scalable, and maintainable application. In that sense, consider 

 development as a large venture with much functionality to maintain and evolve over the years.

 of the Angular application without getting lost in the business labyrinth.

From this foundation, you can take off to have an aerial view of the solution that we will create. Brave enough to continue? As the diagram below shows, let's dig deeper and do the necessary projects.

The scaffolding of a complex micro-font-end solution

The solution proposed will end by creating a 

mono-repo workspace with micro front-end applications and domain libraries

There are a few ways to accomplish that; in my opinion, you should use the 

. Feel free to look for other tools if you disagree.

Those commands create and initialize my workspace with the empty structure. 

# Create an empty Workspace called new-docs
# Configure it to work with several applications. 

npx create-nx-workspace@latest 
  --name=new-docs 
  --nxCloud=false 
  --preset=empty 
  
cd new-docs

# Add Angular tooling for building and serving Angular applications. 

npm i @nx/angular

The Nx CLI is a superset of the Angular one, so you will be proficient quickly. The obtained folder structure is quite empty. 

Having many applications leads us to need some form of hierarchy. The concept of 

 applications appears. You can think of the host as a root, with its branches being remote micro applications. It is the main shell of the solution, and 

Besides the name, a lot of configuration is needed to act as a host and orchestrate the communication between the MFEs and the browser. Fortunately, using NxDevTools will facilitate this task.

Let's create the host application using the NxDevTools generator 

. With no special requirements for the UI, we will stick with the CSS style and prepare the creation of e2e test files that we will use later.

# Create the host web application called shell
#   with the prefix nwd and the css style
#   setting cypress as e2e test runner, and avoid unit at this level

npx nx g @nx/angular:host shell 
  --e2eTestRunner=cypress 
  --prefix=nwd  
  --style=css  
  --tags=type:shell 
  --unitTestRunner=none

A few seconds later, you will get something similar to any other application you previously generated with the Angular CLI. One remarkable difference is that the 

 file is now replaced with a more generic 

 option for the moment. I will tell you their use and meaning later. Get familiar with the chosen prefix 

 for the new-docs app. It will be used across the entire app.

 from the command line and see the default Angular Nx welcome page. Obviously, I encourage you to use the 

 file to run the application with the classic 

{
  "scripts": {
    "start": "nx serve shell"
  }
}

Having a host application is the easiest part. At least you only have one. When creating the remotes, you must consider their size and how many micro-front-end (MFE) applications should be.

, the answer is not straightforward. You are not forced to create a myriad of 

depends more on the team's size and the application's complexity

 than any other consideration. Technologies, teams, and subdomains are the things that come to mind when you think about chopping your monolith. I will show you some guidelines that can help you decide.

Micro front-end applications can be seen as whole pages or partial sections reused in several pages. You can have web components deployed as independent MFEs. In this book, we will focus on the most common full-page approach. Going beyond is a matter of configuration and dynamic loading strategy for components.

Any application developed from scratch is usually based on one technology and coded by a single party or a small set of cohesive teams. This is the case of 

. So, apart from being a demo on a book, the only reason remaining to divide the application into micro-front-end applications is based on the subdomain.

Why are subdomains a reason for having MFEs? Because they are 

groups of related features that share a common language in a familiar context

. You can use natural application boundaries to classify or even outsource development tasks. 

Does this mean a one-to-one relationship between subdomains and micro-front-end applications? No, it is only a guideline. You can have multiple micro-front-end applications per subdomain (if it grows or is very complex). Or you can have a single MFE app for several subdomains (especially the generic ones).

---
title: Applications and Libraries
isPublicLesson: false
useMdx: false
---

# Applications and Libraries.

### What you will learn in this lesson.

In this lesson, we will create **a new Angular workspace** and learn how to build a suitable scaffold for our project. Then, we will discuss deeper options to group Angular code and learn how to choose the best grouping option for each case.

`New-docs` is just a demo application, not a marketable project. But I want to use it to teach you how to build a significant, scalable, and maintainable application. In that sense, consider `new-docs` development as a large venture with much functionality to maintain and evolve over the years.

Let´s **focus on the architecture** of the Angular application without getting lost in the business labyrinth.

## The workspace.

From this foundation, you can take off to have an aerial view of the solution that we will create. Brave enough to continue? As the diagram below shows, let's dig deeper and do the necessary projects.

![Host app Remote apps Libraries](https://d2uusema5elisf.cloudfront.net/courses/angular-applications-architecture/module_03/lesson_03.02/public/host-remotes-libs.png)

### The scaffolding of a complex micro-font-end solution

The solution proposed will end by creating a **mono-repo workspace with micro front-end applications and domain libraries**. 

> There are a few ways to accomplish that; in my opinion, you should use the _NxDevTools_. Feel free to look for other tools if you disagree.

Those commands create and initialize my workspace with the empty structure. 

```bash
# Create an empty Workspace called new-docs
# Configure it to work with several applications. 

npx create-nx-workspace@latest 
  --name=new-docs 
  --nxCloud=false 
  --preset=empty 
  
cd new-docs

# Add Angular tooling for building and serving Angular applications. 

npm i @nx/angular
```

The Nx CLI is a superset of the Angular one, so you will be proficient quickly. The obtained folder structure is quite empty. 

### The host application.

Having many applications leads us to need some form of hierarchy. The concept of _host_ applications and _remote_ applications appears. You can think of the host as a root, with its branches being remote micro applications. It is the main shell of the solution, and `shell` is the name I have chosen for it. 

Besides the name, a lot of configuration is needed to act as a host and orchestrate the communication between the MFEs and the browser. Fortunately, using NxDevTools will facilitate this task.

Let's create the host application using the NxDevTools generator `@nx/angular:host`. With no special requirements for the UI, we will stick with the CSS style and prepare the creation of e2e test files that we will use later.

```bash
# Create the host web application called shell
#   with the prefix nwd and the css style
#   setting cypress as e2e test runner, and avoid unit at this level

npx nx g @nx/angular:host shell 
  --e2eTestRunner=cypress 
  --prefix=nwd  
  --style=css  
  --tags=type:shell 
  --unitTestRunner=none
```

A few seconds later, you will get something similar to any other application you previously generated with the Angular CLI. One remarkable difference is that the `angular.json` file is now replaced with a more generic `nx.json`

Forget about the _--tags_ option for the moment. I will tell you their use and meaning later. Get familiar with the chosen prefix _nwd_ for the new-docs app. It will be used across the entire app.

Go ahead and run the application with `npx nx serve shell` from the command line and see the default Angular Nx welcome page. Obviously, I encourage you to use the `package.json` file to run the application with the classic `npm start` by adding the following script.

```json
{
  "scripts": {
    "start": "nx serve shell"
  }
}
```

### Remote applications.

Having a host application is the easiest part. At least you only have one. When creating the remotes, you must consider their size and how many micro-front-end (MFE) applications should be.

Despite the word _micro_, the answer is not straightforward. You are not forced to create a myriad of _really micro_ applications. A slicing pattern **depends more on the team's size and the application's complexity** than any other consideration. Technologies, teams, and subdomains are the things that come to mind when you think about chopping your monolith. I will show you some guidelines that can help you decide.

-   For different **technologies**, you _must_ cut an MFE app for each _technology_.
-   For different **remote teams**, you _should_ cut an MFE app for each _group_.
-   For different **bounded contexts**, you _can_ cut an MFE app for each _subdomain_.

:::note

Micro front-end applications can be seen as whole pages or partial sections reused in several pages. You can have web components deployed as independent MFEs. In this book, we will focus on the most common full-page approach. Going beyond is a matter of configuration and dynamic loading strategy for components.
:::

Any application developed from scratch is usually based on one technology and coded by a single party or a small set of cohesive teams. This is the case of `new-docs`. So, apart from being a demo on a book, the only reason remaining to divide the application into micro-front-end applications is based on the subdomain.

Why are subdomains a reason for having MFEs? Because they are **groups of related features that share a common language in a familiar context**. You can use natural application boundaries to classify or even outsource development tasks. 

Does this mean a one-to-one relationship between subdomains and micro-front-end applications? No, it is only a guideline. You can have multiple micro-front-end applications per subdomain (if it grows or is very complex). Or you can have a single MFE app for several subdomains (especially the generic ones).

:::note
In the `new-docs` study case, I will only make one remote app for the editor subdomain and one `remote` lib for the `auth` subdomain, as examples. The rest of the subdomains will be bundled inside the main application called `shell`.
:::

This is the command to create the remote application for the `editor` subdomain. Apart from using the specific Nx generator `@nx/angular:remote`, it is similar to any other app but points explicitly to its host.