DEV Community: Alejandro Ramírez Jiménez

Getting started with Microfrontends: Key Concepts and Strategies

Alejandro Ramírez Jiménez — Tue, 02 Jan 2024 13:05:29 +0000

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 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

☝️ Important note
This lecture will focus more on concepts and ideas rather than specific technical solutions.

The main concepts.
- Shell
- Microfrontends
How to identify the different roles
- Shell
- Microfrontend
The technology required and how it works
- Web Components
Polyrepo versus monorepo
- Polyrepo
- Monorepo
- Conclusion
Initial Technical Implementation
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.

☝️ 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.

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.

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.

☝️ 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.

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.
You will learn more about Microfrontends and be able to make your own implementations.

☝️ 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!

When you should embrace MFEs.

Alejandro Ramírez Jiménez — Wed, 13 Dec 2023 17:09:56 +0000

Since some time ago, there has been growing criticism towards Microfrontends (MFEs) with the assertion that "if Microfrontends are needed, it's due to organizational problems."

I think this statement holds some truth as it is indeed related to organizational challenges. However, in these situations, the code must be adapted to address these issues effectively.

In this lecture, I aim to guide you through:

When Microfrontends are neccessary
The problems Microfrontends solve
Unmask the myth that Microfrontends are harmful
The challenges that accompany Microfrontends

☝️ Important note
This lecture will focus more on concepts and ideas rather than specific technical solutions.

☝️ Important note
This is mainly my opinion based on my experience and research.

From a Small Project to a Behemoth
- The First Challenge: Scaling the Team
- The Second Challenge: Budget Constraints
- The Third Challenge: Framework Limitations
- The Current State of the Project
MFEs: A Potential Solution
- Defining Roles
- Module Federation
- Web Components
Emerging Challenges
- Normalization
- Bundle?
- Contractual Coordination
- Routing Considerations
Wrapping it up
Interesting Links

From a Small Project to a Behemoth

When a project begins, it is typically small, manageable, and easy to collaborate.

In the case of a small Single Page Application (SPA), a modulith architecture often provides an efficient and quick solution for web needs.

The team, around 5-10 people, are able to work together, coordinate, have nice DX and develop and maintain features without any problem.

Let's say, the project is a huge seller, it's the golden goose of the company, attracting significant attention.

The First Challenge: Scaling the Team

As the company invests more in the project, seeking to enhance its speed, power, and scope, they increase the team's size. Soon, 20 to 30 people are working on it.

Collaboration becomes more challenging, leading to the team dividing into smaller groups of about 10 people, each focusing on different modules or domains of the SPA. Despite this, it remains a monorepo SPA.

This growth introduces bureaucratic hurdles. Every new feature or library addition impacting the entire ecosystem requires alignment with all teams.

The Second Challenge: Budget Constraints

Over time, some sections of the website gain more popularity or importance, leading to a reallocation of resources and reshuffling of teams. This results in uneven development capabilities across different groups.

Time keeps passing and your favorite framework (Angular❤️) has released a new shining version that brings a lot of interesting features to the table. Some of the teams are eager to upgrade inmediately, because the new control flow syntax it's amazing, but, others lack the resources required to migrate in that moment and can not afford the breaking changes and adapt their code.

The Third Challenge: Framework Limitations

When the product continues to be successful, the company will want to hire more people, invest more resources and make it even bigger, but they find a shocking surprise:

❗They cannot find more Angular developers❗. The company already contains a lot of them, but there are not enough developers in the market, and even less with strong skills in Angular.

Hiring developers from other frameworks and training them poses a significant financial burden.

The Current State of the Project

Now the project is in a tight spot, although the client that uses the application does not feel any of these problems, thanks to modulith, the efficiency of the website keeps feeling contingent, but, our DX is getting worse and worse.

The codebase has grown enormous, leading to long build and deploy times, and local development becoming increasingly painful.

MFEs: A Potential Solution

Defining Roles

After all the problems we have discussed, let's now introduce our hero of the day. Microfrontends.

Let's apply MFEs to the SPA we have been talking about. The first step is to designate the Shell and the others MFEs.

The Shell will handle common functionalities across the application, including authentication, relieving the MFEs of these concerns.

Each team, previously working on a specific module or section, now oversees an individual MFE.

This leads to splitting our SPA monorepo into multiple repositories, one for the Shell and others for each MFE. Each now operates as a separate application with its own deployment and build processes.

Module Federation

Now we can integrate Webpack Module Federation, for example with the library of AngularArchitects.io

☝️ Remember
As said, this lecture focuses more on the idea and concepts. For a technical solution, I recommend reading the series of post of AngularArchitects.io

At this stage, we have already solved:

Team Scalability: Teams can work independently, reducing conflict risks.
Framework Flexibility: Adoption of different frameworks (e.g., React) becomes feasible within teams.

But what about budget constraints?

Web Components

Web components allows us to encapsulate even further our Microfrontends, solving the existing problems with pure MFEs about conflicts in namespace, css and dependencies.

This allows for different Angular versions within the Shell and various MFEs.
For example, the Shell might run Angular 17, while a budget-constrained MFE continues on Angular 15, yet they still function cohesively and they can communicate with each other through Web Component using Inputs and Outputs (Outputs transformed to CustomEvent by itself) or a whole own implementation for communication purposes based on custom events.

☝️ Important note
Module federations allows using shared services for sharing state but when using different versions of the framework this is not longer possible, because they have separated Angular Dependency Injection trees with different root scopes.

Emerging Challenges

Despite its advantages, this new ecosystem introduces its own set of challenges.

Normalization

Now we have so many separate artifacts (Shell and MFEs). Before in our SPA it was as easy as using a shared module, with this new context we cannot do that.
In order to still have normalization of UI components, styles and etc, we would need some libraries. We can develop libraries for normalization to be used in every single artifact.

❗ Important!
I' am using Shared Modules as an example but they are not a good solution for sharing code.

Bundle?

Now our bundles are smaller, but we have a new problem. The bundle now depends on versioning, and Web Components can increase it significantly. If we have a happy path and every single artifact is Angular 17, when the client enters the website, it will load the Shell and the bundles for Angular 17, the users navigates and everytime it loads a MFEs, if using Angular 17, they will just reuse the already download bundle.

Now let's see another reality, where we have the Shell and four MFEs in Angular 17, another two MFEs in Angular 16, and three in Angular 15. What will happen when the user keeps navigating through those MFEs is that it will download the bundles for each Angular, ** increasing the usage of resources in the client.**

☝️ Important note
I have used Angular versioning as an example, but this affects to every single dependency, could be the framework, or any library.

Contractual Coordination

Another thing to keep in mind are the contracts. Now the Shell and MFEs will communicate mainly through Inputs and Outputs, and those are separated in the Shell and MFE, so they have to be very well-defined. This could be helped with shared libraries.

Routing Considerations

The browser of our client has only one url sadly, so this means that it should always be delineated as what is being shown on the screen. If we go to a scenario where we have two MFEs loaded at the same time, and both of them have routing, they will navigate internally but will also modify and replace the url, so now it could be different from what is being shown in the other MFE.

❗ Important!
Only the `Shell` and maximum one `MFE` should have access to the routing

☝️ But soon...
angular-architects is currently developing a library that allows multiple routers, the first stable version should be in the first quarter of 2024

Wrapping it up

In conclusion, MFEs can be an excellent solution to solve a vast amount of issues that are not necessarily because of the lack of organization or planning, but because of the nature of the product itself.

Although, there are always new challenges to be solved when working in this ecosystem. In my opinion, for big projects, this solution is mandatory and new challenges can be solved with robust and thoughtful architecture.

I hope you have enjoyed reading this lecture (my very first article ^^) and that it was useful for you, for any question you might have, you can contact me in any of my linked social media. Thank you!

Also especial thanks to MikeZks for helping me polishing the article.

DEV Community: Alejandro Ramírez Jiménez

Getting started with Microfrontends: Key Concepts and Strategies

The main concepts.

Shell

Microfrontends

How to identify the different roles

Shell

Microfrontend

The technology required and how it works

Web Components

Polyrepo versus monorepo

Polyrepo

When it works

Cons

Monorepo

When it works

Cons

Conclusion

Initial Technical Implementation

Wrapping it up

When you should embrace MFEs.

From a Small Project to a Behemoth

The First Challenge: Scaling the Team

The Second Challenge: Budget Constraints

The Third Challenge: Framework Limitations

The Current State of the Project

MFEs: A Potential Solution

Defining Roles

Module Federation

Web Components

Emerging Challenges

Normalization

Bundle?

Contractual Coordination

Routing Considerations

Wrapping it up

Interesting Links