So, What’s the Deal With Micro-Frontends?

A coarse-grained view of micro-frontends and their trade-offs

Introduction

In software engineering, one of the most important technical decisions you can make is the method of partitioning a project’s architecture. The consequences of this decision cascade, so you must get this right! Unfortunately, there is no silver bullet solution as the correct decision depends on your context. As always, we defer to the First Law of Software Architecture:

Everything in software architecture is a trade-off.

Using micro-frontends is an increasingly popular method of partitioning frontend applications. In this post, I will define them and describe their trade-offs. For those who have more time, I will explore the why, starting with exploring different partitioning styles. I then share a coarse-grained overview of micro-frontends. But first, for those who are in a rush:

TL;DR Micro-frontends, inspired by microservices, break previously monolithic codebases into independently deployable parts that are composed of a greater whole. Deploying frontends independently improves desired characteristics such as scalability, agility, and maintainability. These benefits mirror those of micro-services but also have similar accompanying downsides: operational and governance complexities. Examples include complexities with code reuse, standardised UI, managing interactions between micro-frontends, and deployment configuration.

Before we proceed, if you enjoy this article see my newsletter here.

Partitioning

Before delving into micro-frontends, let us first explore other partitioning methods

Big Ball of Mud

One approach is the Big Ball of Mud partitioning (or lack thereof):

“A Big Ball of Mud is haphazardly structured, sprawling, sloppy, duct-tape, spaghetti-code jungle showing unmistakable signs of unregulated growth, and repeated, expedient repair.” — Brian Foote and Joseph Yoder