In the previous article (Part 1), we explored the issues that Frontend Monolith's cause and the way Microservice architecture could help to fix these. Part 2 will examine ways of implementing Micro Frontend architecture; there have been several solutions for the Micro Frontend problem though none have been 100% effective:
IFrames
These are transclusions that run on the client, allowing you to insert blocks by URL. The frames can communicate via postMessage to one another.
However there are often issues with modals and dropdown menus. There is the SEO problem for search engines. There are frequent performance issues as the same libraries are loaded multiple times and it is expensive to forward messages between windows (CPU).
Web Components
The web standard for browsers. It allows you to define and register dynamic custom items in an encapsulated scope.
The biggest problem with SSR is that web components are heavily tied to the DOM API. It will help encapsulate the component, but won't help make a large SPA application. It could be compared to a slightly wiser iframe, nothing more.
Linked Pages
An approach in which the load balancer, according to the page address, gives one or another SPA application. An example implementation of this is Next.js Multi Zone. The good thing about linked pages is that routing inside the SPA application will be cheap and fast.
A negative is that at one address there is only one application. Also, with this approach, the transition between applications will be "expensive" for the user.
Single-SPA
One of the most popular SPA frameworks at the moment. It requires a thin layer of orchestration, which, according to the URL, launches this or that micro front-end, "turning off" the previous one. For this you can use what you want - React, Angular, Vue.
The issue is we dive into systemjs and mappers, they are not clear with loading assets css, fonts or images. The same libraries are loaded multiple times like with IFrames and you have to embed one micro front-end into another outside the single-spa.
You Could Always Reinvent the Wheel?
Alternatively you could take the time to create your own solution, however this is usually expensive both financially and time-wise due to the amount of research and development, tests and documentation required. Also it would need to be open source to cut costs on research and development
Module Federation is a new plugin feature in Webpack 5 that allows one Webpack application to dynamically load code from another Webpack application. Essentially, it allows you to import chunks from a third-party webpack bundle at runtime. It also allows you to run two or more Webpack manifestations at runtime, making them work together like you compiled them from the start! It uses anything Webpack can bundle (e.g. css, images, fonts) and shares it between micro front-ends!
Module Federation can share with common dependencies if the semver matches. For example, if react is already loaded, then it will not be reloaded from a third-party webpack application.It can also be deployed on different domains and deployed independently! "Build" happens on the fly when the application is launched in a browser.
There are several issues with Module Federation, most notably:
No system is perfect but “Module Federation” is a fantastic solution for the Micro Frontend problem - for the time being.
.png){kind=small}