4 Practical Ways to Build Micro Frontends
Breaking down the frontend monolith to enjoy micro frontends.
For most projects, the frontend world remains largely monolithic. Just as with the backend before micro-services, this means that it’s hard to scale development and that teams keep stepping on each other’s toes instead of being free to independently build, deliver, and choose their own tech solutions. Instead of working separately from each other, developers are all bound to the same codebase of a growing SPA or SSR app and so are all forced to crowd in the same build pipeline. This makes development inefficient and hard to scale.
The idea of micro frontends is to allow the benefits of microservices in the frontend world. Different frontends are built in decoupled codebases, are released through separated pipelines, and are composed together to create a cohesive application that feels unified to the user. Just as with microservices and the DB, each micro frontend can only access its own part of the DOM.
It is important to note, however, that the frontend world provides its own complexities. Naturally, various different approaches and architectures have been developed to tackle these issues with different tools emerging to solve problems for each of these solutions. In this post, I’ll introduce four common ways to build micro frontends. This is by no means a comprehensive guide, rather it’s an introduction to what’s out there and a good place to start the exploration journey. Please do feel free to comment below and add more solutions or insights from your experience.
1. Micro frontends with Bit components (build time and runtime)
Bit (open-source tools) is the most battle-ready, flexible and scalable way to build micro frontends.
With Bit, you can create features, experiences and pages as independent and reusable components — and compose them into different applications.
Read: “How We Build Micro Frontends”
Read: “Dell’s shared building blocks approach to app composition”
Bit’s open-source tools let you create new features, experiences and functionality as components that are completely independent. Meaning, each has its own codebase, dev environment, dependencies (bit manages this automatically), version, package, and release pipeline.
Via bit cloud these components are organized and hosted in scoped, from where they can be consumed (via build time or runtime) into different apps, and updates for new versions can propagate and build the changes.
Bit CLI provides a useful set of features to allow this workflow, including a powerful and modular component-development workspace, smart dependency definitions, sem versioning, automated packaging, etc.
Bit’s tools and platform are being fast adopted by leading enterprises, as it provides a complete end-to-end workflow not just for building micro frontends, but also for sharing and collaborating on them as reusable building blocks at the organizational level.
2. Runtime integration (client-side composition)
The idea here is simple in theory: “Each micro frontend is included onto the page using a <script> tag, and upon load exposes a global function as its entry-point. The container application then determines which micro frontend should be mounted, and calls the relevant function to tell a micro frontend when and where to render itself”. Sounds simple enough, right?
You can deploy each of the bundle.js files independently. You have full flexibility to build integrations between micro frontends however you like. For example, you can download each JavaScript bundle as needed, or you can pass data in and out when rendering a micro frontend. This type of flexibility, and the advantages of the smaller independent payload of each deployment, makes this an idea that people often try to pursue, and try to build tools to support.
One particularly interesting tool is Single SPA — a “Javascript framework for frontend microservices”. In short, it applies a lifecycle to every application. Each app can respond to URL routing events and must know how to bootstrap, mount, and unmount itself from the DOM. The main difference between a traditional SPA and single-SPA applications is that they must be able to coexist with other applications and that they do not have their own individual HTML pages.
So if you’re looking to put together different frontends or frameworks into one DOM and aim to integrate at runtime, check out this interesting experiment.
You can check out some examples here. And, visit the project here:
3. Integration via iFrames
Iframes are the HTML documents that can be embedded inside another HTML document. By their nature, iframes make it easy to build a page out of independent sub-pages. They also offer a good degree of isolation in terms of styling and global variables not interfering with each other.
Let’s go ahead, however, and put it right on the table — Iframes are also, old, cumbersome, and make for a poor developer and user experience. And what happens when elements need to overflow, like a tooltip or a bar? It’s difficult to build integrations between different parts of the application so they make routing, history, and deep-linking more complicated, and they present some extra challenges to making your page fully responsive.
Still, being the traditional go-to solution, Iframes are sometimes used to build micro frontends. It was even shared that Spotify uses Iframes to stitch together different parts of the view. The communication between iframes is made via an event bus that decouples different parts of the application allowing them to communicate without knowing who is going to listen.
Some claim that “this saves a lot of time on managing the application memory because every time an iframe location is changed, all objects are automatically ready to be garbage collected”. True or not, it’s up to you.
Here is a very live demo project on GitHub called “micro-frontends-iframe” that showcases the compositions of iframes as a micro frontends solution. Check it out to see an example app that leverages this type of architecture.
4. Serverside composition
In this approach, micro frontends are cached at CDN and composed in a view, then served to the client runtime or at build time. The server composes the view, retrieves micro frontends, and assembles the final page it serves. If the page is highly coachable it can be served via CDN. If the page is highly personalized, there will be many requests coming in from different clients, so make sure that your server can accommodate and handle this type of scale.
With this approach, remember to delegate caching to the CDN whenever possible, to generate your template server-side, to take care of the page composition at runtime, and to even integrate your web pages with personalized services. For example, this can mean that you have an index.html which contains any common page elements, and then uses server-side includes to plug in page-specific content from fragment HTML files. You then serve this file using Nginx, configuring the $PAGE variable by matching against the URL that is being requested.
For even greater independence, there could be a separate server responsible for rendering and serving each micro frontend, with one server out the front that makes requests to the others. With careful caching of responses, this could be done without impacting latency. There are two old technologies by which we can accomplish the composition, the Server side include (SSI) and the Edge side include (ESI). They are used to combine different HTML markups into one. In both cases, we need to maintain a map of URLs that correspond to static HTML files. Check out these neat projects for example:
Also, take a look at this cool Podium project built to simplify micro frontends via server-side composition. It’s definitely an interesting experiment.
Creating an ecosystem wherein you’re able to scale development and empower multiple teams to independently build, deliver, and choose their own tech solutions is a recipe for success. Too often we sacrifice one for the other, greatly impeding productivity and increasing frustration. Understanding practical ways to build microfrontends is key in striking a balance here. I hope that my article has helped to encourage you to begin integrating these practices into your workflow and to continue improving from there. Thanks for reading! Please feel free to share more ideas or feedback in the comments.
