Using Angular Elements for a micro-frontend

For my latest client, I was asked to look into how we could structure an Angular application so it could be developed in different sectors.

The application is made up of 12 major sections, each section performs a certain task within a workflow. So while each section is linked, they each have their own set of APIs which they use.

We also wanted to have each section be set up so it could be developed by different developers within a distributed team.

So we have one large parent application that manages the login and main navigation. Then within each section, we have a complete sub-application.

Possible Approaches

There were a couple of approaches we could take, one was to load each sub-application within an iframe, but this means that each sub-application cannot have data past into in via @Input() properties and, well frames are an old approach.

We could have created a monorepo, which are extremely popular now in Angular, but the client has already built some of these sub-sections within their own repos. They didn’t want to start changing their approach to their repo structure. Sometimes as a consultant, while you know there is a great new way of tackling a problem you need to hold back and follow how the client wants to work.

Enter Angular Elements

So with these constraints, we decided that a better approach would be to use Angular Elements. With Elements, we could create each sub-section application as a stand-alone app, but still, be able to ‘package’ it as an Angular Element. Then each of these elements can be loaded in the main parent application as a web component.

Another great benefit of Elements is that when we want to make an update to a sub-section, we can simply generate a new main.js file for that element. Then we just replace the new main.js file for that element in the main parent application. Then when the user reloads the parent application the new updates to the sub-section are available. This was a great benefit as it means that when making updates the parent application can still keep running. As this application is being constantly used being able to keep it available and make new releases was a real problem for the client and being able to solve this problem through using Angular Elements was win for the client.

How I implemented this solution

To start with I created two smaller applications, one for each sub-section. Then using the ngx-build-plus library from Manfred Steyer, I managed to build a single file, the main.js file.

Then I created the parent application, for this app I used NgRx because as the functionality of the parent application grows I want to use NgRx to make the app more Reactive.

In this parent app, I built out the login functionality of the app, when a user has successfully logged in we store some needed details in session storage. This data can be accessed by the Angular Elements when they are loaded.

So the parent app has two main routes, one for each sub-section, then in each route, we have the main component that acts as a homepage for the section. This ‘homepage’ component is where each Angular Element is loaded.

Through using Angular Elements we can take these large scale applications and break them down into smaller micro applications. That are easier to develop across a team.

Next Steps

Moving forward, we’re planning on building out each micro application, so they are full-featured apps that can be loaded as Elements.

If you have a large scale application, that either needs to be upgraded from AngularJS to Angular or needs to have sections of the app rebuilt as part of a refactoring project. Then using Angular Elements as a way to make smaller changes over time instead of one large re-write is a great way to go.