介绍了 micro-frontends 的理论，估计大家还是云里雾里的。

我们用一个实例来展示一下 micro-frontends 的威力。

A demo made with single-spa

这是一个非常简单的应用，只有一个菜单和两个页面。 通常情况下，对于如此简单的应用，我们通常不需要考虑什么架构问题。 不过为了演示效果嘛。

使用了哪些 library？

基本的 library 有 3 个

1. [single-spa](https://github.com/single-spa/single-spa)
2. [systemjs](https://github.com/systemjs/systemjs)
3. [import-map-overrides](https://github.com/joeldenning/import-map-overrides/)

大家可以猜一下，这个应用一共有几个 repository ？

答案：4

为什么需要 4 个 repository 呢？它们有什么作用？

1. 使用 single-spa 实现 MicroFrontends，我们需要一个 config app 用来管理全部 app 的状态。
2. 我们有 2 个页面，我们把分别独立成 app。
3. 公共组件和主题也独立成 app。

我们一共使用了 4 个 app，为了 CI/CD 方便，我们使用了 4 个 repository。 当然，你也可以使用 monorepo 管理。

这难道不是更复杂了吗？

对于如此简单的应用，micro-frontends 确实没有必要。 但是，micro-frontends 的场景并不是简单应用，而是庞大且错中复杂的企业级应用。 可能很多人来自互联网公司，主要开发 toC 产品，没有 toB 系统开发经历。

我简单介绍一个我参与的一个 toB 产品的背景，如下：

XXX 系统
2020 年启动，第一版计划 2022 年上线。
业务模块 100+
参与开发人员 50+
上线后，继续添加功能

请问这样的项目有什么问题？

1. 开发周期长，2020 年流行的技术可能 2022 年已经是落后的技术了。
2. 参与人数众多，如果不能清晰的划分业务模块的话，实际开发过程中会出现大量冲突，影响进度。
3. 持续添加功能，为了减少回归测试工作量，隔离是必须的。

综上所述，

micro-frontends 更适合 toB 场景。