微前端与Monorepo
https://mp.weixin.qq.com/s/IyGnceMl-vmQ_cGUxy7isw?poc_token=HC_Mv2ejNE0fAk_-8A8EL7w7J8N3gOZTKU_FAZhd
常见两种方式：
- 本地资源引入
优点是：本地引入，比较便捷； 并且可以使用稳定版，组件迭代挂了，也不影响使用； 缺点是：权限管控问题（非组件提供方也能修改代码）以及，变更要重新构建、信息同步方面的问题；
- Micro Frontend远程引入（服务端加载）
优点是：host更新，使用者能马上用到；并且有host权限才能开发组件； 缺点是：本地调试需要起两个服务，如果host挂了，会连带着你的项目一起出问题；
最佳实践：
- 权限问题：在不获取主系统权限的情况，仍然能使用部分组件服务
- 降级预案：引入新组件的时候，不会影响现有的服务；（避免，”一颗老鼠史，坏了一锅粥“）
- 埋点上报：应用方将新业务引入自己的系统的时候，希望这一部分的数据，上报到自己的应用监控系统中
具体方案
后面好像都涉及一些umi的解决方案了，没太看明白；
鉴权
Monorepo的优点：
https://www.cnblogs.com/guxingzhe/p/17587786.html
nx的官方文档： https://nx.dev/concepts/decisions/why-monorepos
- 统一的依赖的管理，统一的工具链以及统一的工具版本，统一的构建流程，统一的发布流程，还有统一的代码风格；
- 统一的工具，组件，共享函数，逻辑抽离等等促进代码复用；
- 在用一些内部工具的时候，可以直接使用源码
- 原子化提交，设计一个业务或者模块的所有更改都能在同一次更改中提交；
缺点：
- 额外的鉴权（我目前接手的项目是各自独立鉴权，通过代理）
- 大体积打包发布有额外开销
- 可能意外更改其他仓库代码的风险
Monorepo构建和时序相关
问题：
- Lerna会全量构建所有项目
- 依赖的顺序
- 循环依赖
nx解决方案：
- 自动推导依赖关系生成依赖图，确保被依赖的项目先构建；
- 任务图: 自动拆分独立任务，提升构建效率；
- 构建缓存（哈希），提升构建速度
turborepo解决方案：
- 手动指定依赖关系
- 无依赖的项目并行构建，同上；
- 构建缓存(哈希)
如何解决循环依赖的问题？
- 拆分或者定义接口层，让A、B项目都依赖C项目，或者定义接口层，A、B通过interface进行交互
- 懒加载，将循环依赖的部分延迟加载，直到真正需要的时候再加载
联邦模块模式
它允许多个独立构建的JavaScript应用在运行时动态共享代码，实现了真正的"微前端"架构。 替代传统的npm包或者umd（部署到CDN）方式。
- 主应用：负责管理应用的加载和路由
- 远程应用：独立构建，运行时动态加载（提供资源）
优势
- 去中心化，任意应用作为入口，每个应用既可以是主应用，也可以是远程应用；（降低耦合）
- 独立开发，独立部署，互不干扰；
- 增量更新，远程应用更新时，只需要更新对应的资源，不需要重新加载整个应用；
黑话
使用微前端的模块联邦模式，将xx业务拆分为微前端项目， 重复性较高， 需要复用一些组件。
传统的npm包方式， 需要将组件打包， 然后引入， 这样每次引入都需要重新打包， 而且不能保证组件的版本一致性。
使用模块联邦模式， 可以实现组件的动态加载， 不需要重新打包， 而且可以保证组件的版本一致性。
遇到的问题：
- 自己的版本
- 模块重复
- 开发效率低
- 单独维护，维护成本高