DEV Community

Cover image for Using Angular Elements for a micro-frontend
Stephen Adams
Stephen Adams

Posted on • Originally published at

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 they're 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.

Discussion (4)

johannesjo profile image
Johannes Millan

Very interesting approach! Not"ideal", in the sense that it might not be what angular elements was intended for, but it seems to work surprisingly well with all the requirements you got there. It sounds slightly convoluted though. If the parts are really independent there shouldn't be too many conflicts when using git flow. Also I have to wonder how one would assure a coherent look & feel of those different sections, if needed.

Did you encounter any other drawbacks using this approach?

stephenradams profile image
Stephen Adams Author

Hi, so far the only issues I had was with setting up the navigation in the sub-section applications so they still work when running in the parent application, but through using names router-outlets I managed to solve this issue.
As I'm the only developer on this at the moment, things are going ok. It'll be interesting to see what happens when others start working on the app/apps. See if that raises issues, which I'm sure it will.

We're using a UI framework so that helps with the consistent UI.

parth181195 profile image
Parth Jansari

Any way you can share the application on git or a basic demo.we are facing similar problem and we also want preserve state in some way.

stephenradams profile image
Stephen Adams Author

HI, sorry, we can't post the code on github as its an internal app. We are using NgRx for our state management, you could use something like that or use BehaviourSubject Observables to make your own way to preserve state.