English | EN 
A Sogeti insurance client, who is very-forward thinking when it comes to researching new technologies and using those that seem to fit their needs, recently began a discussion around Micro Frontend Architecture (sometimes called “Micro UIs”) and seems set on a course to bring this technology into general use.
Roshit Rajan has written a Sogetilabs post that serves as a “no referrer no opener” to the ideas behind Micro Frontends (“MFEs”), and points out the advantages of using MFEs to solve a number of problems.
For this client, in particular, the advantage of using MFEs is related to the ability to uncouple the work of multiple development teams while maintaining a common “look and feel”.
Rajan’s post provides a good start to understanding MFEs, but I would like to delve further into the details of MFE use, and in particular the issues with using MFE architecture and possible mitigation strategies.
The generic idea of compositing independently-developed UI components is not new–in some sense the creation of the iframe component in HTML is the earliest incarnation of a method to composite components. The use of iframe has fallen out of favor for a number of reasons, but it remains as the genesis of the ideas behind MFEs.
The modern concept of “full stack” development also feeds into the ideas behind MFEs. Full stack development is predicated on the idea of being able to develop and deliver a complete application from the services layer to the presentation layer. To date, this has been in the form of a monolithic UI layer–for example, for an e-commerce website, the home page, the catalog pages, the shopping cart, and so on.
MFE requires support for independent development of UI components that can “work together” and can each be modified and deployed without requiring changes to the other components. Simple, in principle, but the devil is in the details.
Let’s take the issues one by one.
As it is the combined behavior of the individual UI components that is important, there must be a common layer that manages bringing in, placing and rendering each of the constituent components. In a standard UI design this is done by a layer that is developed as part of the UI development and which is closely tied to the constituent components. In the case of MFE this is not desirable as it represents a shared components that all teams must be allowed to modified as needed, and which produces an undesired level of coupling.
There are many solutions to this need, but the simplest is to have a single compositing layer, defined in a standard manner, which provides instantiation of the individual UI components as “packages” by name, and which provides the single entry point for each of these packages. Once this is done, further changes <em>within</em> a UI component should not affect the compositing layer.
This run-time integration can be done in several ways: through iframes, through JavaScript, or through Web Components. The first is not recommended but can serve for simpler systems; the latter two are similar and differ mainly in the fact that the latter allows doing things in a “web component way”.
In any case, the compositing issue is not hard to deal with, and it is the remaining issues that create the most “interesting” problems.
CSS is, by design, an inheritable, cascading, and global framework, which makes reuse by individual components relatively simple. This strength is also a profound weakness: differing styling uses can create a confusing complex of CSS blocks, making the code hard to manage.
This is not a new problem, and can be dealt with in a number of ways: naming conventions (e.g., BEM), pre-processors such as SASS, and even a newer approach that uses CSS in JavaScript modules to apply commonly-named styles only where needed. Any of these can be used with MFE to optimize CSS use.
Like sharing of CSS, sharing of libraries–whether standard JavaScript libraries or client-specific libraries–can create problem.
This first is the inclusion of duplicate copies of a library by individual UI components, increasing delivered payload sizes and thus reducing performance.
Another is the use of differing versions of the same library, and the possible global conflicts that might arise.
These problems are manageable in much the same way as they are for different projects today, through careful coordination of library utilization, and emergent discovery of library sharing needs and subsequent “harvesting” of common code.
In any case, libraries tend to become shared resources, and ownership can become an issue. One solution is to allow any team to contribute code to the library repository, but to select a custodian for managing submissions.
In almost all cases the individually-developed applications must communicate between each other. In order to avoid strong coupling, the desire is to avoid shared state, as this requires coordination between the teams. A better approach is to use events and message passing models, or to use the React model of call-backs and passing data downwards.
Whatever approach is used, it is important to use a model that supports the definition and maintenance of contracts for communication to avoid inadvertent breakages in changes are made in each UI component.
The above is not an exhaustive list of the issues that can plague a group that chooses to make use of the MFE model, but it indicates the sort of things that should be considered in undertaking such an approach.
With due consideration and a measured approach, development in an MFE model can result in increased productivity for application development teams, and the ability to make changes in a rapid and reliable manner for complex applications.
