by
tags:

"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

Micro services 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 a specific functionality. This allows each single services 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 backwards compatibility and system stability.

The term Micro Frontends is a derivative of the micro services 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 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 down time 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, datepickers 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, sub sections and components. The caveat is creating a too complicated composition schema with strict dependencies. These dependencies quickly become entangled and entirely miss the point.

In the next posts I will go over the process of creating a micro-frontend app and discuss in details the best practices for implementation.

Please comment and let me know what you think.