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.
