记一次微前端技术选型

项目背景:

  1. app下架需要把所有页面都迁移到企业微信h5
  2. 规划架构:主应用提供菜单组件和公用方法,然后微应用需要渲染到指定的容器。所以要求微前端框架提供隔离样式的功能、以及通讯功能。
  3. 只给了一个月来接入主应用和子应用。子应用需要推动各部门来配合接入,月初提需求,月底上线第一批应用
技术选型标准
  1. 基于时间紧迫,需要挑选可用,且接入成本低,社区活跃度高,遇到问题可以找到对应的解决方案的微前端框架
  2. 维度与评分
    • 成本
      • 接入成本(接入微前端框架要改动的东西)
      • 改造成本(基于这个微前端框架不支持的功能,需要自己实现的难度评估)
    • 收益
      • 微前端运行时功能完整性
      • 微前端工程化
      • 微前端运维
    • 风险
      • 社区活跃度(github star数量、已解决issue数量)
      • 可维护性(文档是否齐全、在技术社区是否可以找到对应的技术分享文章)
      • 可扩展性(随着越来越多的微应用接入,是否会导致管理上的不便)
iframe iframe有天然的隔离性,但是隔离性太强,导致以下问题:
  1. 刷新后iframe的url状态丢失,无法控制iframe页面的前进后退;
  2. 想实现子应用免登录需要跨域共享cookie,反而导致安全性降低;
  3. 全局弹窗无法实现
  4. 企业微信h5的iframe不支持跨域请求页面,详见这里
因为 微前端运行时功能完整性 不能满足基本业务需求,直接放弃该方案。
single-spa 功能上:
  1. 兼容多框架
  2. html entry
  3. 加载和渲染原理:路由劫持,下载入口html,渲染到目标容器
  4. 不支持js隔离、样式隔离
  5. 不支持应用间通讯
  6. 不支持预加载
  7. 没有考虑微前端工程化和运维
成本:
接入成本:
  1. 子应用需要安装依赖,以及注册生命周期函数
  2. 主应用需要自己编写加载子应用的逻辑
改造成本:
  1. 需要自己实现js隔离、样式隔离
  2. 需要自己实现预加载
  3. 需要自己实现应用间通讯
风险:
  1. 社区活跃度 github star数量 11.3k、已解决issue数量 532(2022.6.27)
  2. 文档齐全,demo多
小结:
  1. 功能上,只做了路由劫持、提供参数填写加载微应用的逻辑。需要自己实现应用隔离、预加载和应用间通讯。微前端运行时功能完整性 低,得1分。没有考虑 微前端工程化微前端运维 相关的功能。所以在收益这个维度,得分 1/9
  2. 成本上,接入需要自己手写加载微应用的逻辑,且子应用需要额外安装依赖,接入成本高,得1分。需要自己实现应用隔离、通讯、以及预加载等,改造成本高,得1分。所以在成本这个维度得分 2/6
  3. 社区活跃度高,可维护性高;
qiankun 功能上:
  1. 基于single-spa完善以下功能:
    a. 应用隔离
    • js沙箱,根据Proxy的支持度以及是否多例,支持三种沙箱实现方式
    • 样式隔离:支持shadow dom方案,以及实验式样式隔离
    • 全局方法(setInterval、clearInterval、addEventListener、removeEventListener)劫持
    b. 支持预加载
    c. 基于props来实现父子通讯
  2. 没有考虑工程化问题:如公用依赖,组件复用
  3. 没有考虑到微前端平台运维
成本上:
  1. 接入成本:子应用需要接入生命周期代码;主应用需要接入注册微应用代码;
  2. 改造成本:需要自己考虑微前端工程化问题,以及微前端平台运维。
风险上:
  1. 社区活跃度:github star 数量 12.8k (统计时间20220622)
  2. 文档齐全,demo多
emp
功能上:
  1. 考虑了微前端的工程化问题,基于webapck5 MF功能解决公共依赖的问题,以及可以实现微组件共享。
  2. 不支持样式隔离和js隔离
  3. 它的设计是去中心化,每个子应用都可以再接入子应用,
成本上:
接入成本:
  1. 所有应用都要迁移到webpack5
  2. monorepo组织几个代码仓库
改造成本:
  1. 基于webpack5 MF实现公共依赖和组件共享,需要另外做基建来统一引入这些包的入口。还有公建文档的问题。
  2. 微组件共享是基于vuera这个库来实现的,只支持vue和react的组建共享
  3. 需要自己实现应用隔离
风险上:
  1. 社区活跃度:社区活跃度不高 star 1.8k (统计时间20220622)
  2. 文档不完善
小结:
emp比较适合大型且处于立项初期时选用。需要事前做monorepo的规划、样式统一规划。
microapp
功能上:
  1. 抛弃了路由劫持的思路,选用类web component的方案
  2. 基于CustomElement和样式隔离、js隔离来实现微应用的加载,所以子应用无需改动就可以接入
  3. 支持应用隔离
  4. 通过劫持底层接口实现了元素隔离
  5. 提供了插件系统
  6. 支持预加载
  7. 没有考虑工程化问题:如公用依赖,组件复用
  8. 没有考虑到微前端平台运维
成本:
接入成本:子应用无需改动,主应用需要接入微应用代码
改造成本:需要自己考虑微前端工程化问题,以及微前端平台运维。
风险:
  1. 这个框架基于CustomElement和Proxy API,前者针对低版本有polyfill,但后者没有,且目前官方文档说没有做兼容的计划
  2. 社区活跃度 star 2.7k(统计时间20220622)
  3. 文档齐全
总结
iframesingle-spa 在功能完善度上不足,所以放弃选择;
emp 比较适合在项目初期选型使用,用约定来规避样式隔离和js隔离(所以 emp 没有把应用隔离考虑进去),比较适合在大型项目中使用;
microappqiankun,功能完整度上比较好,尽管 microappqiankun 多了元素隔离功能、插件系统,且使用了类web component的思路降低子应用的接入成本。但基于 microapp 对 Proxy目前不考虑兼容,且社区活跃度上,qiankun 更胜一筹,工期短需要有一定的保障,所以最后选了qiankun
参考资料:
【记一次微前端技术选型】https://github.com/micro-zoe/...
https://github.com/efoxTeam/e...
https://juejin.cn/post/684668...
https://github.com/efoxTeam/e...

    推荐阅读