Open yang-xianzhu opened 11 months ago
官方给出的解释：
Multiple separate builds should form a single application. These separate builds should not have dependencies between each other, so they can be developed and deployed individually. This is often known as Micro-Frontends, but is not limited to that.
简单理解就是说 “一个应用可以由多个独立的构建组成，这些构建彼此独立没有依赖关系，他们可以独立开发、部署。这就是常被认为的微前端，但不局限于此”
Module Federation以下简称 MF。
MF 解决的问题其实和微前端有些类似，都是将一个应用拆分成多个子应用，每个应用都可以独立开发、部署，但是他们也有一些区别，比如微前端需要一个中心应用（简称基座）去承载子应用，而 MF 不需要，因为任何一个应用都可以作为中心应用，其次就是 MF 可以实现应用之间的依赖共享。
一个使用 ModuleFederationPlugin 构建的应用就是一个 Container，它可以加载其他的 Container，也可以被其他的 Container 加载。
从消费者和生产者的角度看 Container，Container 可以分为 Host 和 Remote，Host 作为消费者，他可以动态加载并运行其他 Remote 的代码，Remote 作为提供方，他可以暴露出一些属性、方法或组件供 Host 使用，这里要注意的一点是一个 Container 既可以作为 Host 也可以作为 Remote。
shared 表示共享依赖，一个应用可以将自己的依赖共享出去，比如 react、react-dom、mobx 等，其他的应用可以直接使用共享作用域中的依赖从而减少应用的体积。
优点：
能够像微前端那样将一个应用拆分成多个相互独立的子应用，同时子应用可以与技术栈无关。
能解解决应用之间代码共享的问题，每个应用都可以作为 host 和 remote。
提供了一套依赖共享机制，支持多版本。
缺点：
为了实现依赖共享需要异步加载各种资源，容易造成页面卡顿。
在引用远程应用的组件 / 方法时没有类型提示。
没有统一的开发工具支持多个应用同时启动同时开发。
什么是 Module Federation？
官方给出的解释：
简单理解就是说 “一个应用可以由多个独立的构建组成，这些构建彼此独立没有依赖关系，他们可以独立开发、部署。这就是常被认为的微前端，但不局限于此”
Module Federation以下简称 MF。
MF 解决的问题其实和微前端有些类似，都是将一个应用拆分成多个子应用，每个应用都可以独立开发、部署，但是他们也有一些区别，比如微前端需要一个中心应用（简称基座）去承载子应用，而 MF 不需要，因为任何一个应用都可以作为中心应用，其次就是 MF 可以实现应用之间的依赖共享。
Module Federation 核心概念
一个使用 ModuleFederationPlugin 构建的应用就是一个 Container，它可以加载其他的 Container，也可以被其他的 Container 加载。
从消费者和生产者的角度看 Container，Container 可以分为 Host 和 Remote，Host 作为消费者，他可以动态加载并运行其他 Remote 的代码，Remote 作为提供方，他可以暴露出一些属性、方法或组件供 Host 使用，这里要注意的一点是一个 Container 既可以作为 Host 也可以作为 Remote。
shared 表示共享依赖，一个应用可以将自己的依赖共享出去，比如 react、react-dom、mobx 等，其他的应用可以直接使用共享作用域中的依赖从而减少应用的体积。
总结
优点：
能够像微前端那样将一个应用拆分成多个相互独立的子应用，同时子应用可以与技术栈无关。
能解解决应用之间代码共享的问题，每个应用都可以作为 host 和 remote。
提供了一套依赖共享机制，支持多版本。
缺点：
为了实现依赖共享需要异步加载各种资源，容易造成页面卡顿。
在引用远程应用的组件 / 方法时没有类型提示。
没有统一的开发工具支持多个应用同时启动同时开发。