Why micro-frontends?

Preface

In the previous article Micro Frontends we explored what micro-frontends are from concept definition and implementation perspectives, and to thoroughly understand micro-frontends, we need to think through these questions:

Why do we need micro-frontends?
What problems can micro-frontends solve? Can't componentization solve them?
What do micro-frontends actually bring? Multiple technology stacks coexisting? Isn't unified technology stack better?

1. Background: Why Do We Need Micro-Frontends?

From initial HTML inline scripts to hundreds of thousands of lines of JavaScript code in 2019, front-end has become increasingly heavy:

Several GB of front-end codebase
Hundreds of front-end developers
Several MB of Bundle Size

And increasingly complex:

Endless frameworks and libraries
Various engineering systems
Unique cross-end practices

Therefore need an architecture pattern that decomposes complexity, improves collaboration efficiency, and supports flexible extension, thus, Micro Frontends stepped onto the stage

2. Application Scenarios: What Problems Can Micro-Frontends Solve?

The concept of micro-frontends is similar to microservices, breaking down the massive whole into controllable small pieces, and clarifying the dependencies between them.

Through splitting autonomy and supporting multiple technology stacks coexisting, solve various problems faced by front-end applications:

How to govern the increasingly intensified coupling between business modules?
How to split and decouple development teams to achieve parallel development?
How to adapt new frameworks and new solutions to existing engineering environment (build tools, etc.)?
How to smoothly upgrade old frameworks and libraries?

Decompose a whole front-end application into a series of smaller, more cohesive micro-front-end applications by business functionality, while managing dependencies between these applications through clear interaction protocols, achieving decoupling of different business modules. And hand over each micro-front-end application to independent teams, each independently developed and deployed, fully utilizing parallelism

On the other hand, with the support of multiple technology stacks coexisting capability, not only can introduce new technical practices at low cost, but also allow low-risk replacement of partial product functionality, meaning major decisions like dependency upgrades, architecture replacements, UI redesigns can all be implemented steadily in a gradual manner:

Decompose: Split application into an application composed of a series of small applications (sub-applications)
Replace: Replace sub-applications
Combine: Ensure replaced ones can work harmoniously

Establish master-slave relationship between applications through micro-front-end framework (1 container application + n sub-applications), then perform partial replacement until all completed. However, in practice usually need to ensure continuous iteration of new features while refactoring, so actual flow may be:

Abstract: Add a layer of master-slave relationship, such as controlling through front-end routing
Extend: Add new sub-applications
Combine: Original application directly as a whole sub-application, go live with new features (newly added sub-applications)
Refactor: (can progress with extension in time) Decompose, replace original application

Let refactoring and other work be completed in a controllable gradual manner over a relatively long time span, without bearing all-or-nothing resource requirements and change risks

Can't Componentization Solve It?

The problems they're supposed to solve sound to me like they're already solved by a good component model. So is this solving an organizational issue rather than technical one? Such as if two teams can't agree on anything, even shared infra.

(From I don't understand micro-frontends.)

Admittedly, componentization can also achieve splitting autonomy, for example in React can elegantly complete code splitting through React.lazy + Suspense method

But this is built on the premise of unified component model (or consistent technology stack), while the other half of micro-frontends' advantage lies in being able to break the limitation of single technology stack:

They are microservices in the browser. Meaning separately built and deployed frontend apps that can choose their own framework and libs. The purpose is organizational scaling and avoiding framework lock-in.

This is something componentization, modularization and other solutions cannot satisfy. Similarly, git submodule, npm module and other splitting solutions also cannot directly provide multiple technology stacks coexisting capability

3. Significance: What Do Micro-Frontends Actually Bring?

Engineering Value

Half comes from benefits brought by modularization, such as:

Improved R&D efficiency: Multiple business lines parallel development, team autonomy, independent iteration
Reduced delivery cost: Application-level functionality reuse
Reduced operation risk: Narrowed change scope

Other half comes from benefits of multiple technology stacks coexisting capability:

Increased technology choices: No longer bundled with single technology stack, helps experimental trial-and-error of new technologies and new interaction modes
Enhanced reusability: Technology stack differences are no longer obstacles to functionality reuse, especially important for third-party modules
Reduced refactoring risk: Low-risk partial replacement, gradually complete large-scale refactoring

Of course, allowing multiple technology stacks coexisting doesn't mean encouraging introducing as many technology stacks as possible, because fewer technology stacks is usually more conducive to infrastructure construction, resource reuse and experience sharing

Business Value

Web applications under micro-frontends perspective are a combination of independent functionalities:

The idea behind Micro Frontends is to think about a website or web app as a composition of features which are owned by independent teams.

(From What are Micro Frontends?)

Therefore, micro-front-end applications can be plug-and-play like cloud services under cloud computing background, achieving application module-level (third-party) functionality access/integration, its business value lies in:

Fine-grained, composable front-end product form: Front-end products/capabilities can be output in finer-grained, more flexible forms (freely combine on demand like cloud services)
Micro-front-end application ecosystem: Standardized micro-front-end applications can form an ecosystem, thereby producing a platform system similar to mini-programs

Reference Materials

Micro Frontends
[I don't understand micro-frontends.](https://medium.com/ @lucamezzalira/i-dont-understand-micro-frontends-88f7304799a9)