This is a living document. Come back often to get updates.
Hello, world
Micro-frontend dev !
Micro-frontends Composable Decoupled Frontends
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.
But what exactly is one micro-frontend?
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.
Let's forget about the name. Decoupled frontends, micro-frontends...
Do you actually need to decouple your application, into smaller parts?
How to use the sliders
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.
-+
-+
-+
-+
-+
-+
-+
-+
-+
-+
-+
-+
Learn more about Application Size
Tip: Slide more to the left if your application is smaller, and more to the right, if it is larger.
When evaluating whether or not your should be splitting your application into multiple microfrontends, you should consider how big your application is.
Large, monolithic applications, even if they are modular and when they are tightly coupled, especially if they have large teams working on them, are candidates for micro-* architectures.
Learn more about Application Type
Tip: Slide more to the left if your application is more static, and more to the right, if it is more dynamic or reactive.
Just like application size, application type can be determinant not only to decide whether a micro-* is justified, but what pattern will be the most effective. Modern frontend frameworks have enabled us to choose the most optimal rendering mechanisms for our application content: universal mechanisms like static site generation, server side rendering, SPAs, MPAs, FPAs, hybrid with partial or total hydration, but also the ability to author content in a completely detached system like a headless CMS, are changing the game and giving us multiple options.
Learn more about CI/CD and release cycle frequency
Tip: Slide more to the left if your application releases less often, and more to the right, if releases more frequently or continously.
One of the most notorious problems of tightly coupled, monolithic systems, is interdependency and the fact that, even the smallest change triggers a version bump, affecting the whole application. For teams working on different streams but bound by a single release cycle constraint, this can be daunting. For the business units behind the application, the lack of sync and different release needs can become a problem to meet marketing deadlines and implement strategies. A tightly coupled system is usually detrimental and plays against the aggressive need for speed of the market.
Learn more about App components are in the cloud
Tip: Slide more to the left if your application is composed with less cloud-native, serverless components, and more to the right, if it integrates more of them.
For a micro architecture to successfully strive, it has to live in the cloud. Only a cloud deployment can guarantee scalability, recovery, elasticity, global distribution and other very important aspects are covered, at a cost that justifies the decoupling. When an app is deployed to the cloud, we have more possibilities, like serverless deployment, that reduce total cost of ownership and enables teams to go faster.
Learn more about Data Models and Databases
Tip: Slide more to the left if your application feature as single data model, and more to the right, if it queries more data types and to different database models.
One of the issues we dealt in the past was the unified data storage, data modelling and databases, the whole application -regardless of the many purposes of its features and capabilities, had to deal with. Data storage tended to be expensive and all components and modules were subject to a single entity in the data access and data storage layer. Conversely, one of the multiple benefits of the cloud are the many options and tools for data modeling, data querying and data storing, that are distributed, managed, and typically cost efficient. This diversity of serverless options and some advanced mechanisms for data modelling and querying specification and management, ranging from Open API, to the multiple API gateways and database as a data platform offerings, are simplifying the way we work with data today.
Learn more about Encapsulation and security concerns
Tip: Slide more to the left if your application needs less encapsulation, and more to the right, if it needs more encapsulation and has more security constraints.
When integrating development by independent teams, and having to choose a mechanism or technical definition, the need to keep code isolated and encapsulated may be a critical and decisive factor, particularly when we plan on integrating micro applications in a vertical split. Other reasons to keep our applications encapsulated, may have to do with business strategies or competing business units in a same platform. We may want to resort to horizontal split.
Learn more about Strict governance and conventions
Tip: Slide more to the left if your unlikely to be able to define and enforce governance, and more to the right, if you are more likely to be able to enforce governance across independent teams.
Micro frontends have been advertised as a way to make teams more independent to choose the technologies they want to work with, and enable independent deployments. However, for very large infrastructure and apps composition, particularly for vertical splits, the lack of agreement, documentation or a governance scheme in general, can suppose a problem larger than the one posed by a monolith.
Learn more about Monolith Backend Apps
Tip: Slide more to the left if your application is more monolithic now, and more to the right, if it is already implementing a modular or microservices approach in the backend.
Monolith backends that are typically worked on by very large teams, and serve the business needs of multiple units, tend to be good candidates for decoupling. This sis specially true when parts of the monolith are developed or maintained with more frequency than the others, forcing a version upgrade of the whole system, even for smaller changes.
Learn more about Ability to respect a performance budget definition
Tip: Slide more to the left if your application budget is likely to be updated to fit new features, and more to the right, if you may be able to respect it over time.
I am really hoping that you have slid that range slider all he way to the right, and your performance budget is very tiny and your team respects it. The smaller the budget, the more you should think about keeping your tech stack to a minimum of choices, or choosing an architecture system that allows you to effectively defer the load of anything that is not immediately necessary or visible above the fold. Keeping JavaScript to a minimum will help your Lighthouse scores stay high and the Core Web Vitals ones low, and for that you should consider leveraging Web Platform APIs or using frameworks that promote zero execution.
Learn more about Maintaining a single tech type
Tip: Slide more to the left if your application will feature a single technology choice for the UI, and more to the right, if it will be a composition of multiple frameworks and other technologies.
Micro-frontend architectures enable us to use different technologies and frameworks, to satisfy different requirements. That enables teams to be more independent, and make their own decisions. But be careful. Without strong governance, the whole application can become and unmanageable splatter of versions and dependendecies on skew.
Learn more about Team size and independency
Just like application size, team size is a determinant factor. In the cloud, smaller teams may choose to deploy parts of their application in composition, and use a serverless execution context to deploy APIs. But keep in mind that the more fragmented an application is, especially when the team is small, the hardest it is to maintain it. For larger teams, however, micro-* architectures help separating concerns, enabling team independence in terms of architecture and stack choices, foster innovation and deliver faster with better results.
The graph and sliders above are made for fun, although they can give you a referential result. They were based on the graphs in slides 52 through 57 of this deck.
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-.
Where do problems come from? The monolith.
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:
Slow time to value
Inability to introduce innovation
Interdependency
Technical debt and bloat
Runtime performance degradation
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.
Are all monoliths bad?
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.
Let's learn more!
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!)
This website uses a technical cookie to save your cookie preferences in your browser. Additionally, it uses Google Analytics to analyze the traffic.
If you continue to use this website, you consent to the use of cookies. Terms of Service and Privacy