An architectural style where independently deliverable frontend applications are composed into a greater whole. This allows us to build full end-to-end verticals and scale our Frontend Development.
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.
In thisd article, we explore the concept of breaking down frontend monoliths into more manageable and independently deployable micro frontends, allowing teams to work in parallel and deploy features autonomously. This approach aligns well with the broader goals of migrating from monolithic architectures to more flexible, scalable microservice-based systems. For a deeper understanding of the strategies involved in such a migration, especially on the backend side, we recommend reading "Monolith Migration Strategies". This article delves into the patterns and practices that can facilitate a smooth transition from monolithic to microservices architectures, providing a comprehensive roadmap for organizations looking to modernize their backend systems in tandem with their frontend applications.
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 Fowlers 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.
Dive deeper into how System Design and Architecture principles play a crucial role in implementing Micro Frontends effectively.
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 NDC London can be found here:
[.blog-divider][.blog-divider]
- Martin Fowler: Microservices, a definition of this new architectural term
- Sam Newman: Building Microservices (Book)
