Introduction to Micro Frontends

“Micro frontends” is a new trend in large single-page applications (SPA). Single-page applications have become increasingly large and resemble in behavior and life-cycle the server-side monolith. Just as there is a movement to split server-side monolithic applications into multiple robust micro-services, there is also a movement towards splitting up the client app into multiple parts that can be developed, and more importantly - deployed, independently thus increasing agility and lowering the risk of unexpected regressions in other parts of the application

Microservices are isolated, self-contained “modules” that together serve a higher logical purpose. They communicate with each other via an agreed-upon protocol and each service is responsible for specific functionality. This allows every single service to remain simple, concise, and testable. Once a service is ready and rested it rarely needs to change. A good practice is to keep the services completely immutable and use semver versioning to notify the environment (other services) of updates and API changes. This serves for painless backward compatibility and system stability.

The term Micro Frontends is a derivative of the microservices approach. It represents the architectural approach for the composition of multiple self-contained and loosely coupled UI components (services), where each component is responsible for a specific UI element and / or functionality.

There are several distinctive benefits that are gained by applying micro frontends to complex web apps:

• Reusable code
• Agility - Independent development and deployment cycles for each service
• Reduce the risk of bugs and regression issues
• Easier testing

It is important to also state the disadvantages that anyone considering adopting this approach should be aware of:

• A complex development environment
• Complex Integrations
• Initial downtime can increase
• Third-party module overlapping/redundancy Composition complexity

There are 3 main implementation approaches:

• Web Components - web components are native implementations of the components that are included in the app such as menus, forms, date pickers, etc. Each component is developed independently and the main app project utilizes them and composes the final app.
• Component Libraries - depending on the stack of the main app the different components and app sections can be developed as libraries and “required” into the main app so the main app is a composition of different components.
• Iframes - The most robust implementation also isolates the runtime environment of the components and app sections so each section can be developed independently and be agnostic go other sections’ technologies - i.e. we can develop some sections in React, others in Angular and more in vanilla Js or any other technology. So long as the iframes are served from the same origin, inter-frame messaging is pretty straightforward and powerful.

The biggest challenge is figuring out how to divide the app. A bad design can become a nightmare to develop and maintain. The main principle is to divide the application into distinctive sections, subsections, and components. The caveat is creating a too complicated composition schema with strict dependencies. These dependencies quickly become entangled and entirely miss the point.