Shrinking the load: A look at Micro Frontends at QCon London

The QCon London enterprise developer event is under way this week, a vendor-neutral event which aims to track the latest trends and pressure points in modern coding.

Microservices is a topic of enduring interest, but another that may be less familiar to some is Micro Frontends, addressed here by AWS principal solutions architect Luca Mezzalira, pictured, who is leading a track on current trends in frontends.

The idea of Micro Frontends is to bring some of the benefits of Microservices to the client, and to avoid the creation of what developer house Thoughtworks called “front-end monoliths – large and sprawling browser applications that are as difficult to maintain and evolve as the monolithic server-side applications we’ve abandoned.”

The concept is to break up the functionality of an application into distinct parts. One example would be to map to pages in a web application, with each part typically owned by a different development team. There may also be a containing application, which covers common elements like headers and footers and authentication.

There are various approaches to deployment. One idea is to compile all the pieces into a single page application – but this removes some of the Micro Frontend benefits. A preferable approach is to build each Micro Frontend separately, and have the containing application load them on demand. One way to do this is to build a separate JavaScript bundle for each Micro Frontend. With this approach it is possible to update each one independently.

Performance and pitfalls

There can also be a performance benefit. Mezzalira told us of a case where an application’s load time had been reduced from 40 seconds to 12 seconds using the technique, which reflects the reality that some parts of an application are more frequently used than others. If a page is not visited, why load the code to render it?

Nothing comes for free, and Mezzalira spoke to QCon attendees about some of the pitfalls. Teams may want to go their own way to some extent, even using different UI frameworks for example, but that is best avoided unless there is a compelling reason as it can bring its own form of bloat.

Another issue is versioning of library code. Perhaps one Micro Framework is considered nearly complete, and its team has little resource, while another is highly active. The stage is set for a form of dependency hell with the shared code, as the active team requires new versions, perhaps with breaking changes. Similar issues can crop up with global shared state. According to Mezzalira, you can minimise problems by using strong documentation, and embracing a loosely coupled architecture.

When should developers consider Micro Frontends? This is an architecture mainly of interest to enterprises, Mezzalira said, where there are multiple teams involved.