Author note: This article is the beginning of a series showcasing Module Federation and its impact on modern frontend development.
Whether it’s on the backend or frontend, modern web applications have been getting smaller this past decade. The rise of micro-frontends followed the rise of microservices. The common rationale was at play: single responsibility applications with low cognitive load were easy to iterate on, and could even be thrown away and started over if needed. IT organization structures and agile processes adapted to the rise of application minification by building product teams aligned with specific sets of functionalities: checkout, search, account, etc. teams arose within digital organizations.
However, with this minification trend arose challenges –
How do all these micro-applications work together, performantly, and unbeknownst to the end-user?
How can teams limit the amount of duplication and conflicting work?
To help address these challenges, enterprises built teams to focus on the “horizontal challenge” caused by many “vertical” product teams. These were architecture teams – teams building design systems or “shared component libraries,” infrastructure teams, or “core services teams.” The app minification trend seemingly helped enlarge IT departments, and in the past year or so, a tipping point was reached.
There has traditionally been a big problem with micro-frontends on the frontend side – namely, how is code shared between them? Common early strategies were to create separate “shared libraries” containing “components” that multiple applications used. But this created its own set of challenges – for example, how are updates handled? When navigating across separate micro-frontends, are we going to download the same component again?
Various solutions have been leveraged overtime to try and mitigate challenges like these: edge-side includes (ESI) was introduced to pull in these shared components in a more dynamic nature at runtime. But modern frontend libraries and frameworks don’t typically like an injection of arbitrary code at runtime. Several open-source libraries have been created to “play nicer” with modern web frameworks like React to counter this challenge. However, they have a challenge: they are still external to an application. There is still a performance cost to an end-user to download the same components or same library multiple times across separate frontends. And this is not even mentioning the problem of “page reloads” across micro-frontends – the ideal web application user experience is what the original “single-page application” was attempting to deliver – a whole website, on a single page.
These challenges with micro-frontends – both technical and organizational, have been significantly mitigated through a breakthrough open-source technology recently released as part of Webpack 5, known as “Module Federation.” Through webpack programmatic configuration, micro-frontends can reference other micro-frontends and dynamically share code (not just components!) directly with each other.
Module Federation allows for eliminating duplicate downloads for not just individual components but shared dependencies across frontends, significantly boosting user experiences. The overhead to maintain “shared component libraries” and sync versions and experiences across micro-frontends is also greatly reduced. The promise of rapid delivery of performant product-based user experiences has never been more achievable through module federation.
To learn more about Module Federation, review the technology’s website. To learn about how AIM Consulting is leveraging Module Federation and the impact, it can have in your organization, request a demo today.
