Pros and cons of micro-frontends

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.

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. This may be a challenge to implement and enforce, and may require a lot of coordination and communication between teams.

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.

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.

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.

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.