This is a living document. Come back often to get updates.
Micro-frontends are the result of breaking down large user interfaces into smaller, more manageable and independently deployable pieces, with benefits at an organizational level.
If you arrived here confused about what a micro-frontend is, I am about to confuse you more. Is a button that hits an HTTP trigger, a micro-frontend? Yes. Is a shopping cart and checkout feature a micro-frontend. Yes, it can be. Is a whole blogging micro-site in the context of a much larger platform with dozens or hundreds of capabiltiies, a micro-frontend? It can very well be.
This is why, although I will be using the term micro-frontends throughout this site, I prefer to think of them as composable decoupled frontends. Not all applications that may be considered a micro-frontend, are effectively `micro`. Please go to the micro-frontend patterns section, to understand why.
For each item, slide all the way to the left for less, less often, less amount, and to the right for more, more often, more amount.
eg: Application size. The application I'm trying to decouple is enterprise size, so I'll slide it to the right. eg: Application components are in the cloud. The application is hosted on-prem, but the database is in the cloud, so I will keep the slider in the middle.
It is normal to feel curiosity and excitement about new tech, and if we investigate a new way of implementing a solution and it seems to be fun and innovative, it's normal to want to use it in our app.
But it's important to understand what problem a technology exactly solves and make sure we have that problem.
Micro-frontends should solve, first and foremost, organizational problems not technical ones.
Even when you do determine you have some or all of the problems a technology or architecture you want to adopt solves, make sure it is with the least amount of effort and complexity, and without generating new, more difficult to address, ones.
Architects typically resort to exploratory and discovery sessions to identify problems and opportunities -scoping-, and then write down a list of requirements, an architecture decision matrix, and a set of constraints, to make sure the solutions they come up with are viable and fit the use-case, with a reasonable amount of effort and time -feasibility-.
Web applications have for many years been built as a three tier or three layers architecture system. The frontend (UI), the backend (business logic) and the data layer (data access and storage).
When I talk about this at conferences, I like to reference additional layers: the infrastructure layer, or the supporting foundation to all, and breaking down the databases layer into data storage and data access.
In a monolith, those layers are tightly coupled, which means that all the components in those layers are interdependent and connected in a way that makes it difficult to change one without affecting the others.
image caption: monolith architecture 3 layers
Some of the problems that arise from tightly coupled applications are:
It comes to a point where maintaining and further developing a monolith that serves multiple business units, becomes a slow process, and it becomes increasingly difficult to introduce new features and innovations.
There are cases when a monolith is the right solution, though. In the frontend, when implementing shared assets techniques, a consolidated design system (abstracted to an upper, consumable layer) and component catalogue, having a unique build system and catalogue of dependencies, and a unified deployment, may be the right way to go.
Although, when that's the case, the recommendation is to modularize the application.
What options do we have to break apart the tightly coupled, monolithic application?
This is my personal site, and I'm going to use it to explore the different options available to decouple frontend monoliths. All opinions are mine and nothing is set in stone!
You can explore the site in the order proposed by the cards below, or at your own pace, to learn about acrchitecture, frameworks, patterns, runtimes, tools and more, available, to decouple frontend monoliths!
Although I will try to be as objective as possible, it's not unlikely that some of my preferences are reflected in this site.
I will also inevitably issue some advise, like STAY AWAY FROM HYPE DRIVEN DEVELOPMENT. IT TYPICALLY `DOESN'T SCALE`.
When looking for information in the internet about micro-frontends or decoupling a monolith, you will come across a lot of terminology. Although, they may make sense in a certain context, many of those terms are just created to market a technology -or to resurface an old one that has been adapted to the new ecosystem, so it feels new-.
This practice is pretty standard and it's valid! The only problem with it is that sometimes it can create confusion, and make you think that you need to use a specific technology or pattern to solve a problem that you may not have (just because the term or the tech seems to be so cool!)