Levels of Indirection and Microfrontend

Does microfrontend have too many levels of indirection and uses wrong level of abstraction?

Micro-frontends are a design approach where a front-end app is divided into smaller, more manageable pieces, each responsible for a distinct feature of the application. They can be developed and deployed independently by different teams.

However, like any architectural pattern, the micro-frontends approach has trade-offs and can introduce complexities. Here are some considerations with regards to levels of indirection and abstraction:

  1. Level of Indirection: A micro-frontend architecture could indeed introduce multiple levels of indirection. Each micro-frontend might have its own routing, state management, and communication with the back end, leading to a more complex overall architecture. You need to establish clear interfaces and contracts between micro-frontends, which is another level of indirection.

  2. Level of Abstraction: A micro-frontend architecture may not necessarily use the wrong level of abstraction, but it can easily fall into this pitfall if not properly managed. Each micro-frontend should ideally be a self-contained app that encapsulates a specific business domain. However, it can be tricky to determine the right level of abstraction, especially when there’s shared functionality across micro-frontends. Over-abstracting (making micro-frontends too granular) or under-abstracting (making micro-frontends too large or encompassing too many responsibilities) can lead to problems.

  3. Duplication: Micro-frontends may introduce code duplication, especially for shared libraries and components. This could lead to larger overall bundle sizes if not managed carefully.

  4. Integration Complexity: Integrating micro-frontends together can be challenging. You need to decide whether to use build-time or runtime integration, and you need to handle issues like versioning and communication between micro-frontends.

  5. Performance: Depending on how micro-frontends are implemented, they can introduce performance issues. For example, if each micro-frontend includes its own copy of React, this could significantly increase the size of the final JavaScript bundle.

To conclude, while micro-frontends can bring benefits in terms of scalability, independent deployments, and team autonomy, they can also introduce complexity and could result in too many levels of indirection if not carefully managed. As with any architectural decision, it’s essential to consider the specific needs and context of your project before deciding to use micro-frontends.