Concept: Microfrontends

A microfrontend is a microservice that exists within a browser.

Microfrontends are sections of your UI, often consisting of dozens of components, that use frameworks like React, Vue, and Angular to render their components. Each microfrontend can be managed by a different team and may be implemented using its own framework. It is practical and suggested to use just one framework for all your microfrontends, although you may add additional frameworks when migrating or when experimenting.

Each microfrontend has its own git repository, its own package.json file, and its own build tool configuration. As a result, each microfrontend has an independent build process and an independent deploy / CI. This generally means that each repo has fast build times.

Microservices are backend services that run in their own operating system process, control their own databases, and communicate with each other over the network.

Compare that to microfrontends that all exist within a single browser tab: all browser JavaScript within a tab exists in a single operating system process (and even thread!). Browser JavaScript generally does not directly access databases, and communication within a browser tab happens in-memory instead of over the network.

So what do they have in common???

Independent builds and deployments. Think of the DOM as the shared resource that your microfrontends are owning. One microfrontend’s DOM should not be touched by another microfrontend, similar to how one backend microservice’s database should not be touched by any microservice except the one that owns/controls it.

In the context of single-spa, a microfrontend is often an in-browser JavaScript module. You can read more about this in the recommended setup.

In the context of single-spa, there are three kinds of microfrontends:

single-spa applications: Microfrontends that render components for a set of specific routes.
single-spa parcels: Microfrontends that render components without controlling routes.
utility modules: Microfrontends that export shared JavaScript logic without rendering components.

A web app may include one or more types of microfrontends. See an in-depth comparison and our recommendations for choosing between microfrontend types.

import { thing } from 'other-microfrontend' is the preferred way to communicate between microfrontends. Here is some documentation that goes over this in more detail.

single-spa is a small, 5kb (gzipped) npm package that orchestrates the mounting and unmounting of your microfrontends. It knows when to mount the applications based on activity functions and can do so in a framework agnostic way with the help of small adapter libraries.

Microfrontends are often more performant than the monoliths from which they originate. This is due to built-in lazy loading (via loading functions) and other performance-related best practices. Your monolith likely has “skeletons in its closet” - microfrontends gives you a migration path that will expose and resolve the problems caused by those skeletons. One important performance consideration is to share a single instance of large libraries (such as React, Vue, or Angular), which is highly encouraged. To do so, see our recommended setup.

Edit this page

Overview

Concept: Microfrontends