An Intro to Micro Frontends

This post is part of a series consisting of multiple Micro-Frontend Architecture Patterns, which we observed during the last months in the course of consulting, workshops and code-reviews in different companies and teams. Although the requirements for the given applications were mostly diverse, there is still a common set of meaningful patterns that should be considered. In this series we would like to explain five of them in detail, and under which circumstances they should be leveraged. The full series can be found here: https://www.squer.at/blog/micro-frontend-patterns/

• Part 1: Micro Frontends — A gentle Introduction.
• Part 2: Backends for Frontends — A tailored approach for performant Micro Frontends.
• soon: Part 3: Integration Patterns — Choose the right weapon.
• soon: Part 4: Progressive Enhancement — The missing ingredient for efficiency.
• soon: Part 5: Monorepos — Maximize code sharing, minimize pain.
• soon: Part 6: Web Components — Technology agnostic component libaries.

Part 1: Micro Frontends

A gentle introduction.

Introduction

We’ve seen significant benefits from choosing a microservice architecture for building enterprise applications, which allows us to structure teams based on business capabilities, improve scalability and enable the flexibility of being polyglot in the usage of technologies. Mostly this architecture is then complemented by a feature-rich and powerful browser application that sits on top of these backend-services. Unfortunately, the latter step ends up way too often in the creation of a single, sprawling and hard to maintain frontend-monolith. The approach of Micro Frontends is an effective way to tackle this problem.

Microservice Advantages to the Frontend World

As Micro Frontends are about bringing the advantages of microservices to the frontend world, we first need to understand what advantages we gain from this architectural style. Martin Flowers phrases them as “independently deployable services” [1], Sam Newman as “Small and focused on one thing, to be autonomous” [2]. So autonomy and independence seem to be the main driver. But what are the advantages we gain from these properties?

I usually summarize the advantages of microservice architectures by following six points:

• Independent Deployments: This one seems to be the obvious one. We can deploy small chunks of our application independently. This allows us to just change a small set of functionality and bring it fast to our customers.
• Distinct Operations: Services are can run fully independently which increases the resilience of our system. To ensure this we must give services autonomy, like for example having their own persistence.
• Technology-Agnostic: We can be technology-agnostic — we don’t have to. Still, it’s usually a good thing if services can be built with exactly the technology or framework which fits our needs best.
• Small Interface Surfaces: The amount of functionality we expose to the outside world is well defined and usually quite limited. We ensure this by following strong cohesion and low coupling in our service architecture.
• Model around Business Domains: In a customer-centric way of creating software we usually want to be able to deliver software in very short intervals. We can best achieve this by creating cross-functional teams, which contain people knowing the business and people understanding how to achieve given requirements with technology.
• Parallel development: Software eats the world. We are building tons of software each day, thus we need ways to parallelize this at some point in time. Building upon microservice architectures usually allows us to achieve this.

The Frontend Monolith

In many cases, this microservice architecture is being completed by adding a monolithical frontend on top of it. As a result, most of the benefits gained through microservices are lost on the Frontend side.

For all of the points I listed up earlier, a monolithic frontend is becoming our limiting bottleneck in the given microservice architecture. As shown in Figure 2 we are not able to do independent deployments anymore, as we can just redeploy the whole frontend at once. Besides this we are not really supporting distinct operations: The chances are high that our whole frontend is broken when one small part in it is not working properly. Up to now, we do not really support to be technology agnostic and modeling around business domains with a monolithic frontend turns out to be a contradiction that is difficult to overcome. But the last point, parallel development usually triggers the problem within companies and shows that there is an issue with their current frontend architecture, as we are usually not able to scale up the speed of development in a monolithic frontend.

Splitting up into Micro Frontends

Micro Frontends are one way to achieve the advantages we gain from modern microservice architectures also in the frontend world. We do so by splitting up our applications in full end-to-end verticals. We tend to call these Micro Frontends, Micro Apps or Verticalized Systems.

There are multiple ways to achieve this, and during this series of articles, we will guide you through the most prominent approaches. It is important to point out that Micro Frontends are not a silver bullet either. Rather, they are suited for a specific set of problems. In a nutshell, Micro Frontends can be a powerful tool to avoid frontend monoliths and this series will give you the needed knowledge to decide if it’s the right one for the job: We start the series with a pattern called Backends For Frontends, which turns out to be a perfect fit for systems following the Micro Frontend architectural style.

Further materials

We are helping and consulting companies in the application of Micro Frontends since 2017. Thus we shared our knowledge at multiple conference meetups. One presentation from Devoxx Poland can be found here:

1. Martin Folwer: Microservices, a definition of this new architectural term
2. Sam Newman: Building Microservices (Book)