5 Pitfalls of Using Micro Frontends and How to Avoid Them

I recently wrote about five reasons why it’s worth embracing micro frontend architecture. Of course, everything has advantages and disadvantages. The micro frontend is a new architectural approach, and is likely to represent the future of web development. At the same time, they come with some drawbacks, and it is important to know them in order to be able to address or avoid them completely.

In this article, you will learn the most important lessons my team and I have learned using a micro frontend. Over a period of two years, we identified many issues with this architecture and made the same number of mistakes. So, it’s time to share them to help you deal with or avoid them.

Let’s first remember what a micro frontend architecture is, and then dive into their disadvantages and how to avoid each of them.

micro frontend in a nutshell

Martin Fowler The micro frontend approach to development defines:

An architectural style where independently deliverable frontend applications are designed to be more complete.

When applied to web development, it implies that there are many independent small frontend applications that are part of the same website or web application. As already mentioned here, this approach was successfully used by my team. Specifically, we had the opportunity to take advantage of all its benefits, such as scalability, technology independence, and maintainability. On the other hand, in the longer term, we noticed some serious issues. Therefore, we decided to abandon this architectural approach in order to return to a more traditional monolithic architecture.

This means that we learned not only the good things that come with micro frontends, but their big drawbacks as well. Let us now delve deeper into these and see what we should have done to avoid or solve them.

1. Unnecessary Dependencies

Each micro frontend application is by definition independent of the others. In other words, a micro-frontend architecture includes more than one frontend application that must be able to function without the others as well. To allow this, they each have their own dependencies. So, overall you are missing out on the benefits of using a package manager. In fact, your entire application will likely have multiple versions of the same library, scattered across the micro frontend.

This is undoubtedly a problem, as it makes your web application unnecessarily large compared to its monolithic counterpart. This falls on the end users, who are forced to download more data. In addition, it affects the rendering time and as a result google web vitals Scores also affect the SEO of your website.

how to address it

One possible solution involves three steps. First, identify the set of libraries common to all microfronts. Second, create a micro frontend containing all the shared libraries. Then, update your micro frontend so that their built packages import the required libraries from this shared project.

As described in Martin Fowler’s original blog post From which this idea comes, sharing dependencies between applications presents many constraints and cannot be considered as an easy task to accomplish. So keep this in mind when trying to achieve this goal.

2. Conflicting and Overlapping Styles

Again, the independence of the technology and the team is great, but it can also present some issues. This is especially true when working with styles. In fact, each micro frontend may not have its own style from a business point of view. This is because you certainly don’t want your applications to look like made up of multiple patches. In terms of style, both UI and UX, everything should look consistent.

Another problem arising from having multiple frontends being part of the same application is that you can end up with unintentional CSS rule overrides. In terms of CSS unwanted overlaps become common when working with micro frontends, and you may only find out about them once you have deployed your application. The reason is that each team usually only works on its own application, and does not see the full picture before deployment.

These issues can negatively affect your brand reputation. Also, end users will pay a price for these discrepancies, especially in terms of UI.

how to address it

When it comes to UI and UX the only possible solution is to ensure that each team talks to the other and has only one outcome in mind. Also, adding style-components to the above shared micro frontend project can help here. Even so, this would make every micro frontend application dependent on it, and it breaks the underlying independence as a result. But at least it will keep your application from looking odd as a whole.

If you want to avoid overlapping CSS, the solution involves adding an id to the frontend container

, Then, configure webpack to insert this ID before each CSS rule. Otherwise, you may decide to adopt a CSS method like BEM (block-element-modifier). It encourages you to think of a website as a collection of reusable component blocks whose class names must be unique within your project. Read Introduction to BEM to learn more about how this system works.

3. Poor performance

Running more than one JavaScript frontend application on the same page will result in slowing down the entire application. This is because each framework instance requires resources in terms of CPU, RAM and network bandwidth.

Also, keep in mind that when testing your micro frontend separately from others, you may not notice this. Problems start when there is more than one instance of a framework running at the same time. This is because, if they are run independently, they do not need to share the resources of the underlying machine, as they would have to do when deployed.

how to address it

One idea to solve this problem is to strengthen team communication to avoid similar calls and elaborations. Then, store their result in a location that each micro frontend has access to, or allow them to communicate before performing a heavy operation to verify if the same data has already been retrieved or generated.

Also, when it comes to performance, you should test the application with all its micro frontends, and should not rely on tests performed on each micro frontend alone.

4. Communication between Frontends

Initially, you won’t need your micro frontend to communicate, except in rare cases. It can fool you into thinking that it will always be like this. Furthermore, although the micro-frontend architecture is about pattern independence, it is opposed to communication.

When the application as a whole grows, enabling your micro frontends to communicate seamlessly with each other is likely to become a priority. Most of all, if you want to repeat the same operations over and over, especially if they are not useless.

Also, as mentioned above, communication is essential to achieve high performance. For example, you don’t want your application to make the same API call twice to get the same data and unnecessarily slow down your server.

how to address it

The solution is to implement a custom messaging layer based on the shared state stored in a cookie or local storage, or on a custom-defined event. As you can imagine, implementing this comes with a cost and can quickly become complex and cumbersome to handle. Also, keep in mind that communication introduces overhead. Therefore, you have to make sure that what you are building will bring real benefits, and will not slow down your application even more.

5. Communication issues between teams

Communication can be a problem in a large team, but nothing is worse than communication between multiple teams. This is because having multiple teams working on different codebases means that it becomes harder to find reusable features, functions, and utilities. This is bad in terms of code discoverability and therefore reusability. In other words, you can easily end up with duplicate implementations of the same components in different micro frontends.

how to address it

The solution is to support the logic of communication between teams from the very beginning. As mentioned above, this involves a project with reusable resources for each technology adopted. But keeping a project like this without keeping it up to date will be useless.

Therefore, you should allow each team to add components and libraries to it. Plus, having a team dedicated to it can make the whole process easier. In fact, it may not be easy for an independent and isolated team to understand which elements will be shared by more than one micro frontend.

Also, don’t think of technology independence as multiple separate teams. Conversely, it is important for the teams to communicate with each other and keep themselves up to date for the success of the project. Thus, fostering a culture of communication should be one of the key elements when adopting a micro frontend architecture.

conclusion

In this article, we looked at the five biggest pitfalls of the micro frontend architectural approach, backed by my team’s two years of daily working experience. Although the micro frontend approach lets developers split a frontend application into smaller independent parts, it doesn’t mean that each team should be separated as well. On the contrary, sharing of solutions, components, resources and knowledge is the key to success.

Unfortunately, we didn’t know it as a team. Thus, we were forced to abandon our micro frontend journey. But we have learned a lot from this adventure, and I hope it has been useful to share the main reasons that led us to failure and how to avoid or counter them.

Thanks for reading! feel free to Please contact me With any questions, comments or suggestions.

Leave a Reply