20 Questions on Micro Frontend Architecture
In this article we'll explore and answer the most relevant questions on the 2022 Micro Frontend architecture pattern.
What is Micro Frontend Architecture?
Micro Frontend (MFE) architecture enables independent deployment of features of an application by vertically slicing the application among multiple teams. Traditionally, teams building a Single Page Application (SPA) would be divided between the frontend, the backend, and quality assurance. Further, large applications may require multiple frontend teams working on a single code base that are divided by feature or role. Often, the result is overhead between these multiple teams building the SPA.
What challenges do MFEs solve?
Building applications at scale require organizational overhead, specifically:
- Organizational management
- Inter-team communication channels
- Knowledge sharing
- Documentation
- Conflict resolution
- Build time
- Dependency and dependency version management
All of these can lead to increased costs and reduced feature development velocity, and therefore, reduced innovation in a competitive market. It should be noted that these challenges are not the only factor in an organization's development velocity.
Micro Frontends seek to address these challenges by reducing the friction and cost of each overhead component as listed above.
What challenges do MFEs introduce?
While an MFE architecture seeks to improve the development velocity of building applications at scale, the architecture introduces another set of challenges that must not be ignored.
These include:
- Micro Frontend Anarchy
- Organizational complexity
- Version mismatch
- Redundancy
- Bundle and code bloat
Let's briefly discuss each of these.
What is Micro Frontend Anarchy?
MFE Anarchy is the result of using multiple frontend (JS) and styling (CSS) frameworks in a single SPA. While using multiple frameworks is technically possible, this leads to large bundle sizes, reduces mobility of team members, requires increased documentation, and increases technical challenges. It is highly recommended to determine a set of chosen technologies when using a Micro Frontend architecture. This ensures not only reduced technical challenges, but this also increases mobility and reduces onboarding and hiring costs.
Does complexity increase?
Yes, managing the complexity of a MFE is not only a technical challenge, but also an organizational challenge. Organizations and leadership must address planning, designing, building, deploying, and maintaining multiple applications and teams that are often distributed. An MFE often requires additional data and state management orchestration services and layers that must be maintained. Further, determining the team responsible for a regression or a performance impact is a new set of challenges introduced by MFE architecture.
Can I have version mismatches?
Yes, using an MFE architecture, you may have each independently built and deployed application with unique and separate dependencies and dependency versions. This may lead to incompatibility and unforeseen runtime exceptions and regressions.
What about redundancy?
While using Micro Frontend architecture can increase the development velocity of team, it often does introduce redundancy. Redundancy is observed across the teams that face similar challenges, need to learn similar toolsets, and solve similar technical problems. Further, if a regression exists in multiple micro frontends, each team must resolve the issue and deploy a hotfix independently.
Does an MFE result in bundle and code bloat?
Overall, it is common to have redundant code between independent applications leading to code bloat. The result is larger KBs of JavaScript code being shipped to the client for executing the application. This is part of the cost of using Micro Frontend architecture that should not be ignored. However, most applications using MFE architecture do not require minimal time-to-interactivity and bundle size, and therefor, this tradeoff is acceptable.
Using module federation we can reduce the resulting bundle and code bloat of an application built using MFE architecture. Module federation enables independent builds to access another container's exposed modules.
Using module federation is a core principle to implementing Micro Frontend architecture in order to share code between applications; either that of a shared external library or that of a local library.
What is an application shell (or host)?
The application shell, or sometimes referred to as the host or container application, is the initial application code that is served to the client that will compose the separate micro frontend applications, or often referred to as remotes. This host application is responsible for bootstrapping the application, routing, sharing configurations, and managing state among the micro frontends.
How do I route between apps?
Routing is slightly more complex when using Micro Frontend architecture.
First, there are routing within an independently deployed micro frontend. In most instances, these are handled internally and are treated the same as routing within a SPA.
Second, there are routes that cross from one micro frontend application to another. You may see this referred to as a "hard" link. In this case, the application shell is responsible for managing the current route, the browser history, and rendering the appropriate components/applications within the browser. One solution for Micro Frontend routing is the single-spa library.
How does inter-app communication work?
Inter-app communication should be limited as much as possible when using Micro Frontend architecture as this violates the goal of independently deployable applications. However, it may be required to use a shared module to expose methods for sharing state and communicating between the micro frontend applications.
Should MFEs share a backend?
It is ideal to use Microservices architecture along with Micro Frontend architecture. In that case, each microservice is independently deployed and is often managed by the same team that builds the micro frontend. Further, Microservice architecture requires that each individual microservice has its own data persistence layer.
What about global state management?
Global state should be minimal, and therefore, using a library such as Redux is often unnecessary. We recommend exposing a shared Observable stream for sharing state.
What about local development?
Ideally, a developer on Team A should not have to build and execute the micro frontend application from Team B. The goal of MFE architecture is to isolate knowledge and code between teams. When using MFE architecture within a monorepo is may be helpful to disable code execution of other applications during local development. When building integration tests it will be necessary for a developer to build and execute multiple micro frontends within the context of the host application.
How do I test my MFE architecture?
Unit and end-to-end testing is the responsibility of each individual micro frontend application. With that said, in order to avoid regressions and incompatibilities between the applications, we recommend building a suite of integration tests.
How do I use design systems with MFE?
A MFE architecture can lead to disparate design choices and frameworks. Design systems work to avoid these issues through unified design language and tokens that are consumed by all applications.
Building your own design system is a large undertaking. We recommend looking first at existing solutions and libraries. Next, we recommend using CSS variables and lit-html for building shared web components that can be used across applications.
What is Single-SPA?
Single-spa is a framework that solves many of the technical challenges of using Micro Frontend architecture, including defining shared modules and routing.
MFE with Monorepos?
Both Micro Frontend architecture and monorepositories seek to solve both technical and organizational challenges, albeit, is sometimes drastically distinct ways. A monorepo can increase code sharing and reuse, provide mobility and insight into applications throughout the organization, decrease build times, and eliminate dependency version incompatibilities. Monorepo tooling also provides insight into the dependency graph of multiple applications as well as distributed computation cache and task execution.
Should I use Micro Frontend Architecture?
The decision to use Micro Frontend architecture is both a technical decision and an organizational decision. As we have learned, using the MFE architecture is not without its own challenges and costs.
Finally, it is important to note that unwinding MFE architecture after a failed attempt can also be difficult and expensive. As such, venture into the world of MFE architecture with an understanding of the tradeoffs, benefits, costs, and potentially, the challenge of unwinding the decision.
How do I get started with a MFE?
There are many paths for getting started with Micro Frontend architecture.
I would recommend the following books:
Can you help me?
Absolutely! LiveLoveApp has a track record of assisting organizations with designing and developing their Micro Frontend architecture.