I used to work for a company building modules for an application that used a micro frontend architecture. I did this for about 3 years and during that time the main problem I saw was the tight coupling between the a module and the host.
Each module had to be on the same version of React, the same version of React Router and the same version of the design system as the host provided each of these. The modules where also tightly coupled to the API provided by the host for things like analytics, feature switching and logging.
Upgrades to any of the common frameworks and libraries were coordinated across multiple teams and took a couple of months because each team had to upgrade, test, wait for fixes, rinse and repeat.
The micro frontend framework was built in-house and there was only one application that used it.
The organisation I am currently working for has recently embarked on building micro frontends but on a much grander scale. We are using Webpack module federation to build multiple applications using micro frontend architecture not across the organisation but across multiple partners as well where each application is comprised of multiple smaller applications. I am the tech lead for one of the teams involved in this effort.
We are not really using module federation to share code between running applications. Rather we have a host and are using module federation to import components from a CDN into the host at runtime instead of build time like you would with npm packages, but the end result is the same.
I bought into module federation as I believed that it would somehow not suffer from the tight coupling that my previous organisation experienced. However now that we are deep into building our first micro frontends I am seeing the same problems begin to emerge.
Micro frontend architecture was inspired by micro services architecture but there is a key difference in my view. With micro services, each service remains independent and communication is done over an agreed protocol such as http. You are not trying to build a monolith service by stitching the code of one micro service into another. This allows each micro service to remain independent in terms of language, frameworks, cloud vendor, monitoring, etc.
Contrast this with micro frontends where you are actually building a monolith out of smaller parts, a kind of Frankenstein with parts that mostly work together stitched onto it plus a few hacks here and there thrown in.
Before we went down the road of micro frontends we had built separate applications which when connected together through urls formed a user flow that took the user from a dashboard to ordering to payment. The user would be hopped from one application to another and this worked, except for the need for each application to refetch data from backend systems instead of being able to share state within the browser. Each application was built and maintained by a separate team.
The reason as I understand it that the organisation decided to switch to module federation was so that code could be reused between applications plus you can more easily share state without taking a performance hit.
However I'm beginning to wonder if it is worth it. You can share common components using npm via your design system or some other ecosystem. My previous company utilised atomic design principles for shared components which I think worked well. For shared state, there is session storage or you could utilise a shared low latency cache. Smart routing rules would allow each application to appear to be on the same domain and a consistent look and feel between applications could be achieved through a design system.
I think that by having separate applications only connected by urls each team gets more freedom and are less coupled together. Plus there are less coordinated upgrade efforts and each team can really move forward on their own without having to worry that they can't move to React 19 because it has some breaking changes with React 18 and they need to wait until other teams have upgraded their apps. Meanwhile they publish a version of their app using React 19 but still have to maintain the React 18 version and double implement new features. etc.
This was a bit long but I would really like to hear the thoughts of the community, especially those who have more experience with micro frontends than I do.
Top comments (2)
I could see this dependency issue you described being a huge pain and leading to a lot of drama, especially in a year or so when the novelty factor wears off.
Do you think this issue is insurmountable to the point where we should shelve micro front ends as a dead meme, or do it’s merits still make it worth pursuing?
Good question and it is something that I've been wondering myself but I'm probably not experienced enough with micro frontends to give a definitive answer.
In saying that however I always prefer to move forward. Micro frontend architecture, like micro service architecture, as I understand it is meant to allow teams to work independently and it mostly achieves that except when there are interdependencies such as shared libraries and frameworks or the need for all teams to use the same tech, which by the way I don't see micro service architecture suffering from.
If we can architect micro frontends in a more decoupled way instead of trying to import whole applications into other applications then I think we can mostly avoid the issues that I have seen so far. Sure, unless an organisation is willing to invest in a design system for different frontend frameworks/libraries such as Angular and React which I seriously doubt, then you will need to pick one. But at least each application can upgrade to the latest version of the design system and other dependencies at their own pace.