This is a step by step guide on how you can create a simple angular application that consumes modules of another application at runtime. But first let’s discuss what microfrontends and module federation is all about.

Introduction

Most people will tell you that microfrontends are like microservices but instead of just doing this in the backend, the concept transfers to doing it in the frontend by encapsulating certain modules/components/pages into independent parts and consuming them dynamically. This means that you could have an application running on port 5000 and in another application running on port 3000 you can use modules from the other application without having them implemented in the application on port 3000.

This is all true, but I would argue that there are more things that make microfrontends interesting.

Why should you use microfrontends?

Short disclaimer: not everyone — actually most people — should not use microfrontends because they make things more complicated. Overengineering is never good, but if you see one of the following reasons applying to your situation, microfrontends could be interesting.

1. You have many frontend teams working on different features. In that case a microfrontend architecture is less of a technical decision but rather a business decision because it will allow teams to really work independently. Otherwise, working with a monolith can sometimes be difficult because you never know for sure if your changes might affect another team in some way.
2. Your application is too big. If you find yourself not knowing where to put models, components, modules, … because your project structure is enormous, then microfrontends will help you create a better separation of concern. By using a Nx monorepository and creating shared libraries you are forced to think more carefully about the architecture and doing things sloppy will be more difficult.
3. If you want to make independent deployments. You could make just a minor change in one of the microfrontends and then you do not need to redeploy the entire application, but instead you can deploy only the one microfrontend that has been changed.

In conclusion, I would even reduce the reasons speaking for microfrontends I mentioned to this one-liner:

Microfrontends are interesting if you have either a huge organisation or a huge application.

What are monorepositories?

I mentioned that our applications will live in a monorepository — that means they are all in the same workspace/repository. Monorepositories have many different appeals but the biggest one I would argue is that they solve a lot of version conflicts because we do not need to publish libraries into npm, but instead consume them directly out of the project. This also means that we only have one angular.json and one package.json so that we have the same package versions in every project. By this rule it would not be possible to have different angular versions or any other varying package versions. In this tutorial we will use Nx to create a workspace which basically is just such a monorepository in which we can store multiple apps and libraries. We could even mix projects of different frameworks in this workspace.

Step by Step Guide

Setup

1. Create a Nx Workspace.

npx create-nx-workspace@latest

• it will prompt you to specify the name of the workspace and a first application. You can already select Angular and give your application a name — but it would not be a problem if you start with an empty workspace since we will add another project anyway.

2. Install Nx

npm install -g nx

3. Create an Angular application (remote)

nx generate @nrwl/angular:application remote

4. Add the module federation plugin to both applications

ng add @angular-architects/module-federation --project=remote

ng add @angular-architects/module-federation --project=shell

Remote Application

So now we will create a simple AbcModule which only routes to the blank Abc component. Then we will expose this module by adjusting the webpack.config.js.

1. Create AbcModule + Routing

ng generate module abc --project=remote --routing

2. Create Abc Component

ng generate component abc --project=remote

3. Configure abc-routing.module.ts

4. Configure app.module.ts with routes

(this is not neccessary for the microfrontend but simply so that the microfrontend would work standalone as well)

5. Expose AbcModule in webpack.config.js

The remoteEntry.js file is auto-generated and needed to give instructions to outside applications containing the webpackconfig configurations. It exposes tells which mappings should be shared and which things it exposes. If you run the remote application you could also just look into this file by adding it to the url like this: https://localhost:4201/remoteEntry.js

Shell Application

Now the only thing remaining is the actual consumption of the microfrontend. There are basically two ways of doing so: Static and Dynamic.

Doing static we would have to define the remotes in the webpack.config.json and also declare the modules to tell typescript that it should not worry about remote modules which it cannot compile. This is a little tedious and also dynamic is much better because we could theoretically even load the microfrontend configurations from a backend.

1. Adjust and configure remotes in webpack.config.js

2. Load the microfrontend lazily when the route is activated

loadRemoteModule is an alternative to statically defining the module in the webpack.config.json and referencing them in the routes. This way we only have to specify the configuration in the routing and we could dynamically load this from other sources as well.

And do not forget to also import AppRoutingModule in the AppModule ;)

3. Adapt app.component.html to have a router-outlet and a routerLink

Let’s go!

Everything is set to run now and should work. Let’s start both applications, but keep in mind that we should start the microfrontends before the shell.

nx serve remote

nx serve shell

Isn’t this crazy? We are using a module which does not even live in our application, but instead runs in its own application. And when doing dynamic loading we could manage the microfrontends in the backend and decide to reference certain modules on the one day and other modules on the next day.

Conclusion

I think that microfrontends and module federation are really interesting although I also believe that it is good that not every company uses it. It helped me get things more organised in my frontend and forced me to take more time to think about the architecture leading to a better software ultimately. It took much time to move a monolith to and Nx monorepository with libraries and microfrontends, but it paid off in the end for me.

There are even more interesting scenarios where module federation is interesting. One would be if you are trying to migrate a legacy AngularJs application to Angular. By using Microfrontends you could gradually move to a new framework. Who knows, maybe in the future Angular will die and we would like to migrate to a whole new framework — microfrontends got us covered on doing so.

I also highly recommend you to look into content by Manfred Steyer who is an expert on these topics. I did not try to explain why webpack.config.js is need for example because I could not describe it as well as Manfred, so check out what he has to say:

If you liked this article I would really appreciate a follow and like!