I recently wrote about five reasons why it’s worth adopting a micro frontend Architecture. Of course, there are pros and cons to everything. Micro frontends are a fresh architectural approach, and are likely to represent the future of web development. At the same time, they come with a few pitfalls, and knowing them is critical to being able to address or avoid them completely.
In this article, you’ll learn the most important lessons my team and I learned while using micro frontends. Over a two-year period, we identified many issues with this architecture and made just as many mistakes. So, it’s time to share them to help you tackle or avoid them.
Let’s first recall what the micro frontend architecture is, and then dive into their pitfalls and how to avoid each of them.
Micro Frontends in a Nutshell
Martin Fowler defines the micro frontend approach to development as:
an architectural style where independently deliverable frontend applications are composed into a greater whole.
When applied to web development, it implies having many independent small frontend applications being part of the same website or web application. As already mentioned here, my team had used this approach with success. In particular, we had the opportunity to take advantage of all its benefits, such as scalability, technology independence, and maintainability. On the other hand, over the long term, we noticed some serious issues. So, we decided to abandon this architectural approach to move back to a more traditional monolithic architecture.
This means that not only did we learn the good things that come with micro frontends, but also their major drawbacks. Let’s now delve into them and see what we should have done to avoid or address them.
1. Redundant Dependencies
Every micro frontend application is independent of the others by definition. In other words, a micro-frontend architecture involves more than one frontend application that should be able to work also without the others. To allow this, each of them has its own dependencies. So, looking at the whole, you’re losing the benefits of using a package manager. In fact, your entire application will likely consist of many versions of the same libraries, scattered across the micro frontends.
This is undoubtedly a problem, because it makes your web application unnecessarily larger than its monolithic counterpart would be. This falls on the end users, who are forced to download more data. Moreover, this impacts the rendering time and consequently the Google Web Vitals scores, also affecting your website’s SEO.
How to address this
A possible solution involves three steps. First, identify the set of common libraries across all the micro frontends. Second, create a micro frontend containing all the shared libraries. Then, update your micro frontends to make their built package 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 obstacles and can’t be considered an easy task to accomplish. So keep that in mind as you try to achieve this goal.
2. Conflicting and Overlapping Styles
Again, technology and team independence is great, but it can also introduce some issues. This is particularly true when dealing with styling. In fact, each micro frontend can’t have its own style from a business point of view. This is because you definitely don’t want your applications to look composed of many patches. Everything should look consistent, both in terms of style, UI, and UX.
Another problem deriving from having multiple frontends being part of the same application is that you can end up with unintentional CSS rule overrides. Undesired overlaps in terms of CSS become common when dealing with micro frontends, and you may find out about them after only deploying your application. The reason is that each team usually works only on its own application, and doesn’t see the whole picture before a deployment.
These issues can negatively affect your brand reputation. Also, the end users will pay the price for these inconsistencies, especially in terms of UI.
How to address this
The only possible solution when it comes to UI and UX is to make sure that each team talks to the other and has the same outcome in mind. Also, adding styled-components in the aforementioned shared micro frontend project could help here. Nevertheless, this would make each micro frontend application depend on that, and it breaks the underlying independence as a consequence. But at least it will prevent your application as a whole from looking heterogeneous.
If you want to avoid CSS overlapping, a solution involves adding an ID to the frontend container <div>. Then, configure webpack to insert this ID before each CSS rule. Otherwise, you could decide to adopt a CSS methodology such as BEM (Block-Element-Modifier). This encourages you to think of a website as a collection of reusable component blocks, whose class name should be unique within your project. Read introduction to BEM to learn more about how this system works.
Continue reading
5 Pitfalls of Using Micro Frontends and How to Avoid Them
on SitePoint.
Source: Site Point
Originally posted 2022-01-31 09:00:04. Republished by Blog Post Promoter