模块联合是实现微前端的正确方法吗？

Question

背景

我正努力想出一种方法来建造微锋。

以下是我的实际情况：

• 团队1:开发名为"ShellApp“的shell web应用程序，它将嵌入(主机)其他微前端
• 团队2:开发一个名为"ChildApp“的微前端web应用程序，它将嵌入到"ShellApp”中。
• 两个团队都可以独立地选择自己的web框架。
• 这两个团队都是独立的，必须独立地部署它们的应用程序。
• 如果两个团队都需要集成，那么他们需要为他们的集成点制定一份合同。
• 还有其他的微锋，将在稍后推出。
• 嵌入的微前端会有自己的路由，并且除了简单的组件之外，还会有自己的复杂性，因为它们本身就是真正的应用程序，可以真正独立。

iframe逼近

将"ChildApp“嵌入到"ShellApp”的老式方法是使用iframe，并设置一个反向代理作为UI和API的代理。

根据我在实施iframe方法方面的经验，利弊如下。

专业人士

1. 更干净的隔离:他们各自的CSS和JS捆绑包只会影响他们自己的站点，因为他们生活在自己的文档上。父母不能影响孩子，反之亦然。
2. 松散耦合/按URL约定:家长只需要了解子应用程序的URL，而不需要了解任何有关实现细节的信息。
3. 集成更简单:如果父程序希望与其子节点通信以显示page2，那么它只会将URL设置为https://childapp.com/page2。

cons

1. 沉重:如果shell应用程序和子应用程序共享相同的库和框架，它们将被加载两次。
2. 有限的集成:更改URL和倾听其更改只能做这么多事情。但是我不确定这是否是一个缺点，因为紧密的集成往往需要实现细节，并且可能是脆弱的。

模块联邦方法

后来，我偶然发现了模块联合，这对我来说是新的。据我所知，与其嵌入iframe，不如异步加载JavaScript模块，将其内容插入shell应用程序的DOM中。

从我收集到的信息来看，这里有一篇文章是关于在具有不同框架的MFE上使用Module的，然后他又提出了一些看起来“丑陋”的解决方案。

让我们从多框架和多版本微前端架构的第一条规则开始:不要这么做;-)。

问题

模块联合是更好的方法吗？根据我的看法，以下是一些警告。

1. 紧密耦合/按模块收缩: ShellApp现在需要知道如何正确使用ChildApp公开的组件，就像对待任何其他JavaScript模块一样。
2. 突兀性:所有球队都必须配置一个额外的捆绑配置，这必须是webpack。
3. 泄露实现细节: ShellApp必须知道用来编写ChildApp的web框架。另外，如果ShellApp和ChildApp都实现了路由，那么它们必须是确保他们一起工作，因为从技术上讲，ShellApp和ChildApp都在同一个文档上。
4. 缺少隔离:因为ShellApp和ChildApp生活在同一个文档上，它们的CSS样式需要和谐地工作--甚至在使用Shadow时也是如此(例如，背景色仍然会影响ChildApp。最后，我能够亲自尝试)我不确定这是否真的是一个警告，因为它可能是一个好处取决于你如何看待这个问题。

Answer 1

请注意，模块联邦并不是完全的解决方案。它只处理JS文件的动态加载，并且可以定义应该多次使用的依赖项(而不是多次加载)。

但是，您可以以WebComponents的形式实现这些childs。

如果您的ChildApp是作为一个WebComponent实现的，那么您的ShellApp只需要知道接口。因为“子”看起来就像一个普通的HTML元素。

而且ShellApp不需要知道任何关于子实现细节的信息，比如使用了哪个框架。

不过，如果您想使用不加载依赖项两次的特性(比如child1的角11和子的第二个角11 )，那么您需要遵循Webpack模块联邦规则。这意味着孩子们至少要知道Webpack的MF会起作用。