Micro-frontends and composable frontend architectures
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.
This website uses a technical cookie to save your cookie preferences in your browser. Additionally, it uses Google Analytics to analyze the traffic. That helps me decide what content is the most helpful and where to invest my time to continue to develop and evolve it.
If you continue to use this website, you consent to the use of cookies. Terms of Service and Privacy
What is this site about?
Welcome to ✨microfrontend.dev✨. Throught out this website, I try to share with you all I have learned working as a full-stack developer and architect across multiple companies, for the past 20 years. You will find a lot of relevant information to frontend and cloud development, code samples, and references to a real life micro-frontends architecture. If this content helps you or inspires you, please let me know and share with others. 🙏❤️ Natalia
What is a 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? The short answer is, yes.
Are a shopping cart and checkout feature a composed into one view or page 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.
Do I need micro-frontends in my application project?
Let’s forget about the name for a moment. Doesn’t matter if we prefer to call them Decoupled frontends, or micro-frontends…Do we actually need to decouple our application, into smaller parts? What can help us better decide?
The following feature offers you a dynamic set of sliders, to assist you in making a decision.
How to use the feature slider
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.
-+
-+
-+
-+
-+
-+
-+
-+
-+
-+
-+
-+
Tip
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.
Creating solutions with micro-frontends
Micro-frontends -or decoupled frontends- solve problems. 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.
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-.
Architecture and patterns
Learn about micro-frontends architecture, patterns and anti-patterns.
Learn more!
Frontend frameworks and standards
Connect patterns to frameworks and tools and learn to get the most out of them.
Learn more!
Micro-frontends pros and cons
What are the pros and cons of micro-frontend applications?
Learn more!