This is a living document. Come back often to get updates.

Microfrontends

Pros and Cons

Do not find a problem for a solution

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.

The adventure

Decoupling your frontend can be an adventure full of advantages, though. Let's review some of them

  • Scalability

    Each frontend application or component can scale independently, and also the entire application can scale out by adding more micro-frontends.

  • Independent deployability

    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.

  • Team independence

    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.

  • Faster time to value

    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.

  • Reducing costs

    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.

The challenge

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.

  • Governance

    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.

  • Ochestration

    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

    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

    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.

  • Data Architecture

    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.