在日本开发 SaaS 产品,爱猫、爱读书、爱大海

2020-06-25 Micro frontends 2: A demo made with single-spa


介绍了 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 场景。