If you’re familiar with the microservices concept, you’re going to get micro frontends, too, immediately. It’s like integrating the separately built and deployed micro applications, UI included, into a unified app. Micro frontends’ beauty is that these mini-applications can be maintained and deployed by separate teams and built with different front-end frameworks.
It’s opening the door to a whole new space of reusability. Imagine an enterprise framework that is adopted company-wide and where a dedicated team is working on the general-purpose navigation components. Then, another team is working on the chat component, and another one is building the contacts application. Everything is integrated into a single email application. Sound familiar?
This pattern has been widely adopted by enterprises, including Google and Microsoft, the latter building a pretty exciting framework called FAST.
The idea behind micro frontends is to think about a website or web app as a composition of features that are owned by independent teams. Each team has a distinct area of business or mission it cares about and specializes in. A team is cross-functional and develops its features end to end, from the database to the user interface.
However, this idea is not new. It has a lot in common with the self-contained systems concept. In the past, approaches like this went by the name of frontend integration for vertical systems, but micro frontends is a more friendly and less bulky term.
Source: https://micro-frontends.org/
Integrating it all together
The Microsoft FAST framework is built upon the Web Components standard in which one can compile the components built in virtually any existing modern JS framework, including Vue, React, and Angular. Web Components are a great option to integrate different frontend frameworks by bundling the application down to the least common denominator: Custom Elements API. In this case, the Browser’s DOM became the API through which the components can communicate up and down via query selectors, events, etc.
With the rise of new integration frameworks like Frint or single-spa, the integration is much more comfortable.
The single-spa framework
The single-spa framework is great because it introduces an abstraction layer over the micro frontends that makes the integration more manageable and straightforward.
First, the developer defines the single-spa root config, which renders the HTML page and the JavaScript that registers applications. Then, the numerous applications and parcels can be written and composed together.
A neat create-single can generate the configuration-spa CLI tool. The community around the framework created a set of framework-dedicated helpers for building particular apps, too.
The way we register the individual apps is relatively simple. You need to import the single-spa Application API compliant JS script and mount it under “activateWhen” url. Applications don’t necessarily have to be mounted under individual URLs (e.g., header)
The framework dedicated utils help compile the apps to the single-spa compliant API and to help developers optimize the bundle. For example, there’s a ready-made webpack config provided with the predefined “external” exports, so each Vue or React based framework doesn’t have to import the whole framework bundle on its own. It will be required just once.
The individual applications must return “bootstrap,” “mount,” and “unmount” functions to be managed adequately by the single-spa framework. That’s it!
The single-spa framework supports not only the application layout integrating the micro applications on the client’s side. It helps the server side rendering, too, in which the individual applications can generate and return the HTML by themselves.
The single-spa layout framework is excellent. You can just mark by using the custom-elements syntax where the individual applications need to be rendered.
Data exchange between the apps
The single-spa team does not recommend sharing any state between the applications, which makes perfect sense. It’s like with the microservices sharing the common database: the quick win or a shortcut that quickly becomes a burden that’s slowing down or even breaking the independent service deployability.
However, what’s recommended is to create shared JS modules with a reusable API like authorization features. It’s pretty much the same way we recommend in the Designing Headless Frontend framework ebook.
Another option is to use event-based communication.
Further reading
Of course, the single-spa documentation is an excellent source for further reading. Please also check out the Qiankun framework based on single-spa but enriched with some production-grade features.
Published February 22, 2021
