MFE Based Applications
Micro-frontend architecture is a modern approach to front end development where a web app is split into self-contained components. These components are built separately but assembled together to appear as a single product to end-users.
Introduction
The logic behind micro frontends is similar to the concept of microservices with the exception that micro frontends relate to the client side of web solutions, not the server side. Following a micro frontend approach makes the most sense when it comes to creating complex web-based products. Unlike a more traditional front-end monolith, micro frontends allow multiple teams to work independently on different pieces of software. With this architectural style, programmers can develop web apps faster, achieving a higher level of scalability and maintainability.
Comparison with Others (Table)
Front-end monolith | Micro frontends | |
---|---|---|
Codebase | Large and bulky | Split into small manageable modules |
--- | --- | --- |
Deployment | Common cycle for the whole system | Independent cycles for each module |
Feature development speed | Standard; may slow down over time | Fast (features may be released independently by autonomous teams) |
Maintenance | Hard to maintain | Relatively easy to maintain |
Stability | Insufficient (a glitch may break down the entire system) | High (a glitch in one component has a little or no impact on the system) |
Updates | Lengthy (may require significant code rewrite) | Can be pushed quickly |
Tech stack | Single stack for the entire system | May be different in the various modules |
Testing | Lengthy and difficult (even a small change requires testing of the entire application) | Quick and easy — for individual frontends Difficult — for the web system as a whole |
Team | A single team working on the project | Multiple teams working on the project |
Budget | Depends on the project size and complexity | Always requires significant investments |
Pros & Cons
- Pros
- Technology agnostic: Its architecture gives flexibility to the individual teams to choose the tech stack for their microservice, which improves and makes the development cycle fast with enhanced features.
- Faster and isolated development and deployment: The development process also highly improves by adopting its architecture. As with this architecture, we can have smaller independent teams that work on different features, and the development and deployment process becomes faster.
- Individual testing and less regression issues: With isolated teams on the front end, the development, testing and deployment cycles become smoother and help build resilient applications.
- Maintainability: The monolithic applications are bound to become large and, hence, harder to maintain. It is built on smaller parts help maintainability through the divide and conquer approach. This ensures easily testable smaller features, and the overall time for testing is reduced.
- Scalability: With the modular and decoupled micro frontends architecture, we can scale up an application to multiple teams as a new frontend element or changes to the existing frontend would not affect the rest of the frontend and other team's work. So this allows a team with different backgrounds and skills to choose the tech stack for their microservice accordingly and focus on continuous growth.
- Cons
- Complicated Testing of a Web Solution As a Whole When a web solution is based on a micro-frontend architecture, testing its individual modules is simple. But it's not the same as testing a web app as a whole. You'll need to validate that all components work together as intended. Given that micro frontends are independent and have their own delivery pipelines, this might be challenging.
- Development and Deployment Complexity A micro-frontend architecture can also cause some complexities in the development and deployment processes. For example, autonomous development teams working on the same project can clutter a solution with too many components, which may lead to some issues at the deployment phase. Also, it's not always easy to assemble all the modules correctly and make them fit seamlessly into the bigger picture — this task usually requires a good knowledge of all the dependencies.
- Inconsistency of Chosen Technologies Micro frontends allow development teams to use different technologies within a single project, which helps to avoid technology lock-in. But this advantage also has a flip side. When front-end frameworks for different modules aren't chosen thoughtfully, you risk ending up with an inconsistent tech stack. This can result in a bunch of issues, from slow performance to an unpleasant user experience.
- Difficulty of Keeping the UX Cohesive When teams work independently on different pieces of software, it's difficult to keep the user interface cohesive. All the developers engaged in the project should have a common vision of the web solution. Otherwise, numerous inconsistencies may occur along the way.
- High Initial Investments Micro frontend projects usually require significant investments. Gathering and maintaining multiple front-end teams is costly. Plus, you'll need management staff to plan the work, coordinate everything, and ensure effective communication between teams.
Best Practices to implement
- Different practices to implement Micro Frontend Architecture-
- The Single SPA meta-framework combines multiple frameworks on the same page without refreshing the page, such a React, Vue, Angular 1, Angular 2, etc.
- Multiple single page application lives at different URLs. For shared functionality applications, use NPM or Bower components.
- Isolating Micro apps into Iframes using Windows. Post Message APIs and libraries to coordinate. IFrames share APIs exposed by their parent window.
- Different modules to communicate over a shared events bus. Each module is working on its own framework, as long as it handles incoming and outgoing events.
Examples
- Some examples of when using micro frontends:
- Your web solution is complex, based on microservices, and can be split into multiple self-contained verticals. For example, you're building an enterprise resource planning system consisting of several modules (e.g., finances, CRM, HR, inventory).
- You want to have different tech stacks for different modules within one web solution.
- You already have or are going to engage a big development team (or multiple teams), and your budget allows this.