This is a living document. Come back often to get updates.
Trying to find a problem to fit a certain pattern, set of principles or paradigm, just so we can implement it, is not the way to go about in software development.
Introducing innovation can be attractive and tempting, but if you're not solving a real problem, it may cause more harm than do good.
Decoupling your frontend can be an adventure full of advantages, though. Let's review some of them
Each frontend application or component can scale independently, and also the entire application can scale out by adding more micro-frontends.
Each frontend application or component can be developed and deployed independently, and may be able to fail in isolation, rendering the whole application fault-tolerant.
Each team developing a micro-frontend can make their own architecture and tech stack decisions. This enables the team to experiment, innovate, and have their own cycles and processes.
Independent deployability and teams, make it possible for them to iterate and ship faster, using the right tools to be more productive, and the technologies they're better at.
Moving some workloads to their own deployment scheme and service, particularly when moved to the cloud, may reduce the total cost of ownership and computing, or capacity needs of the whole application.
Every rose has its thornes... It is important to understand that every architecture pattern and decision has its trade-offs. And so do composable architectures.
For the implementation -including the UI definitions- to remain consistent across the whole application, particularly across the many views when that may be a requirement, and for certain conventions to be respected there should be a strong and strict governance definition that may need to be enforced to all teams.
Governance is key to ensure that the user experience is not compromised, and it's also a guarantee of compliance with legal requirements, and other SLA's like security, privacy, and accessibility compliance, across the whole application.
Orchestrating the deployment of decoupled components or micro-parts may require additional efforts, and even an additional piece of technology to maintain. The recommendation is to delegate this task to the same team issue governance, who will be in charge of any common framework, library, shell or monorepo, when applicable.
Routing is one of the common challenges of application design, and it's a very important aspect of both user-experience and data architecture. It is even more challenging when we're orchestrating decoupled frontend experiences, particularly when the routes of nested components may need to be exposed to the user.
State management is potentially the most challlenging aspect of composition, since an out of sync state can cause the application to behave erratically and even expose security or privacy flaws. Imagine a user being authenticated for some components and not for others. Or some components misinterpreting the authenticated user authorization role.
Or a banking application where the user's balance is not being correctly sync'd across the different components.
Together with state management, data architecture, particularly for transactional workloads, can suppose a major challenge. Imagine a gaming application that constantly saves all user scores to the database in real-time, and every sees a different score.