微前端技术小记

1.技术回顾

回顾web得发展，我把JS引用分成了几个阶段

• web早期

早期大家用script标签引用jquery以及一些常用得ui库等工具库，由于早期页面交互较少，引用得库也少，成熟得库还可能有cdn加速，同时不同页面间还能共享缓存，基本上足以满足需求

• web技术井喷

随着web技术得发展，页面以及不再是单纯得页面，业务复杂读开始不断上升，原生工具库逐渐不够用了，同时出于业务与安全等需求，js代码逐渐出现了以下几个状况：

1. 需要管理源码，远程模块存在安全问题
2. 模块数量增多，资源请求增多，开始影响首屏加载性能
3. angular、react、vue等框架得出现，使得现代得web页面开发不断得生产更多得JS

实际上问题比上述还要复杂，总之就是出现了需要管理和打包js代码得需求，出现了各种打包工具，通过打包工具管理和整合js代码已经成了web开发工具链上必备得一环

2.js代码打包

• 优点

打包带来最直观得优点，莫过于减少了html需要加载得js文件数量，减少了http请求数，因此提高了前端加载得性能

• 缺点

1. 但随着web应用复杂度得上升，打包后得js代码包也越来越大，原本通过减少http请求数节省得时间，也由于js包太大下载慢而导致页面秒开率降低
2. 项目迭代时，往往会出现改动得是上层业务代码（实际上大多只是部分文件改动），底层模块通常不会更改，但是由于打包，导致再微小得改动也需要打包输出一个全新的文件，使得前端文件缓存失去了意义

• 问题的解决

为了解决这些问题，出现了分包的逻辑，通常会按以下逻辑分别出包：

1. 第三方模块
2. 公用组件
3. 业务模块

其中又会有按页面分割，和按模块大小分割等逻辑，但根本目的都是为了分包，分包后一方面减少了单次传输时间，另一方面利用了浏览器可以同时发送多个http请求的优势

分包的局限性

在我之前开发一个页面编辑器的低代码平台时出现了一个需求，我的编辑器和编辑器使用的模块组件，不应当在同一个项目里管理，因为如果当作一个项目开发管理，会遭遇如下问题：

1. 难以自由添加新模块，每添加一个模块，就需要重新打包发布项目
2. 难以对旧模块进行修改 ，每修改一个模块，就需要重新打包发布项目
3. 难以做模块版本管理

实际上问题不止于此，总之因此，我自行搭建了一套开发工具实现了模块独立开发整合，编辑器远程引入的逻辑（最早试图通过webpack来解决，但是无奈未发现合适方案）

在开发期间我便思考一个问题，单个项目通过分包的形式已经可以较好的管理代码，但多个应用之间呢？

1. 多个项目间很可能也存在公用的第三方模块和组件，但是即使分包打包，不同的项目间相同模块也无法混用（hash值不一定相同），如果能混用，浏览器缓存便能起作用，多个项目能用不小的收益
2. 多个项目间如何保证不出现同名模块内容不同问题？用命名空间吗？如何告知通讯？

因此分包虽然能解决单项目的js打包问题，但是针对多项目的情况（大公司烦恼），就有点力不从心了

webpack Module Fedration

扯了这么多，主角终于登场了，webpack module federation（后面我就简称MF），其核心逻辑是有host和remote两个角色，其中host可以通过import引入remote的代码，而host和remote两个完全是独立的两个项目