Getting started with Microfrontends: Key Concepts and Strategies
Tags: javascript, frontend, angular, microfrontends
Published: 2024-01-02 13:05:29

This lecture is aimed at individuals who are considering learning about MFEs and potentially implementing them in their current projects. I strongly recommend reading the [the first article](https://dev.to/this-is-angular/when-you-should-embrace-mfes-2bng) since it will give you an overall image of this series.

In this lecture, I aim to guide you through:

* The main concepts.
* How to identify different roles
* The technology required and how it works.
* Options when distributing the code.
* Initial technical implementation

| :point_up: Important note         |
|:---------------------------|
| This lecture will focus more on concepts and ideas rather than specific technical solutions.      |

- [The main concepts.](#the-main-concepts)
  - [Shell](#shell)
  - [Microfrontends](#microfrontends)
- [How to identify the different roles](#how-to-identify-the-different-roles)
  - [Shell](#shell-1)
  - [Microfrontend](#microfrontend)
- [The technology required and how it works](#the-technology-required-and-how-it-works)
  - [Web Components](#web-components)
- [Polyrepo versus monorepo](#polyrepo-versus-monorepo)
  - [Polyrepo](#polyrepo)
  - [Monorepo](#monorepo)
  - [Conclusion](#conclusion)
- [Initial Technical Implementation](#initial-technical-implementation)
- [Wrapping it up](#wrapping-it-up)


## The main concepts.

When we are talking about the Microfrontends world, the `MFE (Microfrontend)` is the main concept used to talk about this, but there are a few other concepts that you should know:

### Shell

A `Shell` is an application that can work independantly, typically with an architecture almost identical to a `SPA (Single Page Application)`. It's distinct feature is that the Shell can host another applications, known as `MFEs (Microfrontends)`.

### Microfrontends

A `Microfrontend` is a application that *cannot be displayed by itself*. The purpose of a `Microfrontend` is to be hosted by a `Shell` and will act as a piece of it, the difference being invisible to the user when browsing the website.

| :point_up: Important note         |
|:---------------------------|
| A `Microfront` can be also used with a `standalone operation`. It is an architectural decision supported, being the most useful use case for local development.      |




## How to identify the different roles

Now that we have our two main pieces identified (`Shell and Microfrontend`), it's time to differentiate the parts of the current `SPA (Single Page Application)`.

### Shell

When we talk about a `Shell`, we talk about a host, about a container, and about what's common and mandatory in a `SPA`.

If for example, our SPA is a `modulith`, or applies `frontend DDD`, then we have to look for the part of the application that invokes the different *modules* or *domains*.

Our `Shell` should be in charge of distributing the different sections of the application, and bringing to the table the common space for them to load. Normally what a `Shell` contains and does, is a header bar, handles the authentication, and handles the shared procceses.

### Microfrontend

When we talk about a `Microfrontend`, we are talking about a section, a piece of an application, and just a certain area of the `SPA` that does not need to communicate or has dependencies with other areas.

Following the example of the `modulith` or `frontend DDD` SPA, it's time to look for the lazy loaded modules or domains that our application contains.

For instance, in a banking application, if the `Shell` encompasses the header bar and the authenthication procceses, our Microfrontends could be the *Accounts* section, or the *Credit Cards* section.

Another way of looking at it is the Microsoft example, where Microsoft suite is the `Shell` and the different applications such as Word, Excel, Powerpoint are the `Microfronts`.

Our `Microfrontend` should be responsible for a very specific area of the entire application. This area normally is independent from another `MFEs` (areas) but still needs the `Shell` context in order to see the whole picture.

![Representation of Shell and MFE roles where the MFEs are inside of it](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ok2sumz1iqgl9x33hn4m.png)


## The technology required and how it works

Now that we have established the concepts and identified the different components, the next step is to understand the neccesary technology for this ecosystem.

The technology used is called *Module federation*. This technology aims to have multiple separate builds that will form a Single Application when combined.

You can read more in depth [here](https://webpack.js.org/concepts/module-federation/).

Again, using an example of `modulith architecture`, what we are looking for is that those `lazy loaded modules`, that will be *remote modules* and are going to be known only at a runtime.

Now mixing this with the concept we have talked previously, what we are looking for, is that the `Shell`, will load those bundles at *runtime*. Being those bundles, the `Microfrontends`, whose have been built before, now have it's bundles exposed.

### Web Components

A `Web Component` or `Custom Element` in certain aspects is similar to a `Microfrontend`. It's an encapsulation of some part or the whole application. This Web Component can be loaded with HTML tags, for example `<my-webcomponent></my-webcomponent>`.
It is used to implement multi version or multi framework in the ecosystem.

| :point_up: Important note         |
|:---------------------------|
| A Web Component is a piece that not neccesarily has to be used in the Microfrontend ecosystem, but often appears.      |


## Polyrepo versus monorepo

When it comes to code distribution, we primarily have two options, `Polyrepo` and `Monorepo`. 
Now that the application has been sliced into different parts, it can be appropriate to divide the repository into multiple repositories.


![Representation of Monorepo and Polyrepo, portraying the git icon in monorepo just one time and in polyrepo for each project](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qhwkd7dit1d98ov9tzoo.png)

### Polyrepo

#### When it works

* When the different teams need **large autonomy, different pipelines, resources and isolation**. This normally fits for large companies where the final application is only one, and every small part and team is and has a whole different world with their own budget and resources.
* Where the **different teams are small**, it becomes more approchable with the project.

#### Cons

* Sharing code: Since each project has its own repository, it can be challenging to share code between projects. This can lead to duplicated code and a lack of consistency in dependencies, which can increase the risk of errors and make it more difficult to maintain the codebase over time. However, this limitation **can be mitigated by implementing effective dependency management and common libraries developed by the company.**
* Make it harder to have shared dependencies because of potentially different dependency versions.

* Demand for better coordination: With separate repositories and teams now **the need for good coordination increases**. Especially in this ecosystem of Microfrontends, where Shell and Microfrontends have to communicate with each other to ensure a correct implementation. 

### Monorepo

#### When it works

* There aren't too many teams. It also works with a great number of them but it is a different approach on how to develop a common application (suite).
* When a lot of code has to be shared between projects.
* Developers have way easier access to all the code across the applications
* When the pipeline of CI/CD can be the same accross different parts.

#### Cons

* Large codebase, that slows down every git interaction.
* If different parts need different pipelines, it will be harder to implement than usual.
* Limited flexibility of languages and frameworks, while it's still possible in monorepo, it increases the complexity and makes it harder to maintain.

### Conclusion

In either option, `monorepo` or `polyrepo`, have been and are being used by big enterprises so don't worry about what options are the best. **What is important is what fits the situation the best.**

## Initial Technical Implementation

In this lecture I am not going to go through a full technical implementation, but, I strongly recommend the very same book I learnt from the first time I discovered `Microfrontends`. It's the amazing book from **AngularArchitects.io** named **Enterprise Angular: Micro Frontends and Moduliths with Angular**. You can download by free [here](https://www.angulararchitects.io/en/ebooks/micro-frontends-and-moduliths-with-angular/). 
You will learn more about `Microfrontends` and be able to make your own implementations.

| :point_up: Important note         |
|:---------------------------|
| Before continuing the series of article, I strongly recommend completing the book completely.      |

## Wrapping it up

With this lecture, you should now be able to understand the main concepts about Microfrontends and also be able to apply them to an existing project and get some code running. In the following articles, different challenges and solutions will be explained in more depth.

I hope you have enjoyed reading this lecture and that it has been useful to you, for any question you might have, you can contact me in any of my linked social medias. Make sure to follow me for more content about frontend!. Thank you!