This article doesn't delve into setting up the Micro-Frontend architecture; instead, its focus is on highlighting the risks associated with this approach.

Be Careful with Micro Frontends

Micro-Frontends do have a captivating allure, particularly in terms of scalability and the myriad of possibilities they offer. However, I recall a presentation where the author portrayed this architectural approach as the holy grail - something nearly perfect without consequences.

Today, I'll share my perspective on this and emphasize the risks I see, particularly from the client's standpoint in terms of cost.

Definition and Theory

Micro-frontends is an architectural approach breaking down a frontend web application into smaller, independent, and loosely coupled modules. Each module represents a specific feature or functionality, allowing independent development, deployment, and maintenance.

The primary goal is enabling independent teams to work on different features within a larger system, minimizing conflicts. The aim is to decouple teams from a single framework or stack, letting them use any JavaScript framework or library. An Orchestrator manages and coordinates these micro-frontends within the overall application, loading them in one place.

  +------------------------+
  |        Main App        |
  |      (Orchestrator)    |
  +------------------------+
        |       |       |
  +-----+-----+-----+-----+
  |   MF1   |   MF2   |   MF3   |
  | (Module)| (Module)| (Module)|
  +---------+---------+---------+

In this diagram, the Orchestrator serves as the main container or application shell. MF1, MF2, and MF3 are distinct micro-frontends or modules comprising the overall front-end application. Each micro-frontend can be developed and deployed independently.

Tools like NX from NRWL and the Module Federation technique have significantly simplified the setup and maintenance of this architectural concept compared to the past.

Benefits

Micro-Frontends aim to resolve dependencies between teams working on unrelated parts of a system. They target reduced build time, faster delivery, fewer required deployments, and overall flexibility for teams to choose their preferred stack.

The Build Time

Imagine a scenario where a team working on a Chat Widget needs to push a hotfix in a huge system already deployed to production. In architectures like Modular Monolith, triggering a deployment for the entire system may take 15 minutes due to its size.

Micro-Frontends offer a significant advantage here. You only need to build and deploy the small Chat Module as a standalone unit, orchestrated by the main app container. This reduces the build time to 20 seconds, showcasing substantial benefits.

Independent Work

Independently working on features becomes easier with Micro-Frontends. It also facilitates implementing large team management frameworks like SaFe since it mandates working independently on separate code bases and integrating them in a single Orchestrator layer.

Technological Flexibility

Enjoy the flexibility to work with anything you prefer. Picture a Chat Widget in Svelte for optimal Run-Time performance. That's the beauty of Micro-Frontends - seamlessly embed UI parts in different frameworks or libraries.

Encapsulation

Teams operate with separate pipelines, independent builds, and testing cycles. In the end, only one team needs to handle work on the Orchestrator layer, aligning with the Single Responsibility Principle. There's minimal risk of impacting others' work unless you touch the Orchestrator.

Consequences

Realizing that nothing in life is perfect is a crucial insight into a developer's journey.

Complexity

In terms of implementation, setting up a Micro-Frontend architecture correctly, even with tools like NX or Module Federation, can seem complex. Though it's easier now, it can still be challenging and time-consuming.

The Risk of Huge Duplication

Imagine a scenario where a code segment, like utilities, is needed in two or more modules. You have to create a separate module loaded into others, correctly configuring an Orchestrator layer to prevent duplicating code within the core layer.

Money Burning

As a client, imagine needing to hire Svelte + React + Vue developers instead of just React devs due to a shift in the stack. This multi-stack approach can lead to significant developer salaries, especially without ample funds to maintain diverse teams. If the product doesn't generate expected revenue, finding and affording such developers becomes a challenge.

Infrastructural Duplication

Each module requires independent configuration for test environments, pipelines, etc. Solutions like Docker or GitHub Templates can address some issues, but it's crucial to acknowledge the substantial initial effort needed to set up and prevent duplication for each new module.

Huge Experience Required

Expecting every developer to handle complex problems in module integration or the Orchestrator layer isn't realistic. Solutions like these demand architects or individuals with extensive experience in Micro-Frontend solutions.

State Sharing

Imagine a Chat module needing information from the User Module - it necessitates an intermediary or exposure via browser mechanisms like Local Storage or Query Parameters. In a Micro-Frontend approach, significant conceptual changes generally demand more effort than in a simple Modular Monolith approach. Why is that?

1. You need to change the Chat Module, test it, deploy it.
2. You need to change the User Module, test it, deploy it.
3. You need to change the Orchestrator, test it, deploy it.
4. You need to use some kind of versioning to avoid big bangs.
5. You need to coordinate this work between teams.

In a Micro-Frontend strategy, starting from scratch is often favored over modifying existing code.

Design is Required (always)

Venturing into Micro-Frontends without proper planning can be highly risky. Unlike more conventional solutions, this concept is less forgiving of mistakes, requiring careful consideration and meticulous planning to avoid pitfalls.

Summary

Raising essential questions and doubts about Micro-Frontends is crucial. Flashy stacks don't always guarantee a superior user experience or cost-effective solutions. For an investor, evaluating the potential benefits against the risks and complexities introduced by Micro-Frontend architecture is paramount.

Though Micro-Frontends excel, particularly within a unified framework like JavaScript and React, challenges persist. The capability to swiftly build and deploy isolated modules with minimal downtime is a standout feature. The key lies in striking the right balance for the project's unique needs and constraints.

Implementing Micro-Frontends successfully requires strong communication, collaboration, and proactive problem-solving among teams. This teamwork is crucial in projects involving various individuals or teams. It underscores the importance of a robust team culture and open communication to tackle daily challenges effectively.

I prefer MF when it's tied to a small stack and ecosystem. It offers rapid deployment and loose coupling, akin to the Micro-Services approach on the server side. If you've dealt with MS, you understand the problems it addresses.