Each micro-frontend is a npm package that is published to the private registry and then consumed by the “main” app, which combines several of these micro-frontends into a single app that appears to the user as a monolith.As a result, each mFE has its own repo, CI pipeline, and is often handled by a distinct team.
single-spa is a one-of-a-kind framework that creates a scalable micro front-end architecture using the in-browser module and SystemJS import maps. It may be used in a variety of ways, but this tutorial will focus on the suggested technique because it is the most straightforward way to learn and use the library.
An overview of the System JS import map
SystemJS is a free, open-source JS library that is frequently used as a browser polyfill. A polyfill is a JS script that adds contemporary functionality to outdated browsers that don’t support it.
Import map is one of SystemJS’s capabilities, allowing you to import a module over the network and map it to a variable name.
At least one remote-hosted application plus a root configuration that downloads and displays the application over the network make up a single-spa micro front-end.. As you’ll see in a minute, named imports will be utilised in the single-spa root configuration.
Import-maps are used to integrate mFEs at run time.
Import-maps is a proposal for directly resolving ES imports in the browser.
When you write:
import { omit } from ‘lodash’
The browser is unsure where to seek for lodash source. Import-maps enable us to map lodash to a URL using actual code.
It is currently not completely supported by browsers; in fact, it is only supported by Chrome, and you must activate a specific feature flag to utilise it. As a result, we have to employ the SystemJS module loader to support the majority of contemporary browser versions.
Instead of publishing npm packages, mFE pipelines were altered to output system-js compatible bundles and deploy them to CDN. In addition, we built a second repo that contains import maps JSON files and its own pipeline; the pipeline in this repo’s goal is to update JSON with When we need to deploy or rollback the mFE, we’ll use a new bundle file name.
The import-maps repo pipeline with GitLab downstream pipelines feature is triggered by the mFE CI pipeline, which passes the updated version filename. This file name is used to update the import-maps JSON using jq before it is committed to the repository and published to CDN. As a result, in their own pipelines, mFE CI does not need to contain any code related to updating import maps.
So, to make a little change, such as changing the colour of a button, we no longer need to rebuild the main app; instead, we can create and deploy mFE separately, which has boosted delivery speed to production by nearly thrice.
Benefits
- Greater flexibility for mFE teams
- Build speed and deployment time are now entirely reliant on mFE pipeline speed main app has become more detached and independent on mFE’s and its build time has dropped nearly thrice
- The staging deployment takes only a few seconds. (simply changing the name of the bundle file in the staging import-map JSON)
- It takes seconds to rollback.
Drawbacks
Of course, there are some drawbacks: the main app bundle shrinks, but mFE’s bundles now duplicate some of the dependencies that were deduced during the main app build. Although we separated react and react-dom to shared packages, maintaining a large list of shared packages may become a burden that no one wants to bear. As a result, the overall size of materials downloaded by end users grew. The overall size of all JS assets is now twice as large, although with caching improvements in mind, this isn’t that awful.
Reference:https://blog.bitsrc.io/implementing-micro-front-end-with-single-spa-and-react-eeb4364100f
Image credits: https://www.cuelogic.com/blog/micro-frontends-frameworks
Similar Posts:
- No similar blogs
