微前端建筑建议

Question

我们有几个web应用程序，我们希望在一个单一的页面应用程序下呈现。我们正在寻找一个微前端架构/框架来使用。在我们看来，这些是我们执行的备选方案：

1. 使用单一spa开源框架：https://github.com/CanopyTax/single-spa
2. 使用Iframes (友好的Iframes)托管应用程序( shell)，并根据当前的url加载每个应用程序。
3. 编写我们自己的Javascript框架
4. 另一个？

当前状态是一个monolith FE应用程序，它将其他子应用程序作为内部第三方包使用。对于我们来说，这种方法是不可扩展的，因为宿主应用程序正在一起构建所有的产品，并且没有任何东西是真正分开的。

我们的要求是对微型前端的通常要求：

1. 独立开发--每个团队都可以选择自己的框架并构建自己的产品，而不考虑其他产品。
2. 独立部署--每个应用程序都可以在生产中升级，而不需要停机，也不需要干扰其他应用程序。
3. 共享组件--我们在应用程序中使用Angular4，我们有一个专有的第三方库(共享组件和逻辑)，我们已经编写了这个库，应该在所有产品之间共享，以获得相似的外观和感觉。
4. 我们希望有能力升级每个应用程序的框架(角，RXjs，类型记录等，以及我们的专有组件库)，而不关心其他应用程序。

我们试图使用单一水疗框架，但我们有一些问题，我们目前发现我们的自我思考，如果这是正确的方法，或我们应该尝试另一种方法。

我们使用单一水疗中心的问题是：

1. 资产加载是有问题的。(我们必须将资产文件放在宿主应用程序的根文件夹上，并且在切换到另一个应用程序时会遇到资产冲突)。
2. 我们仍然不知道如何处理所有应用程序的全局样式(我们使用sass进行样式设计，并且必须与每个应用程序的本地样式一起使用)
3. 升级角框架(或所有其他框架)对于一个应用程序来说是不可能的，它是全部或根本不可能的(因为我们有一个角的实例)。
4. 我们必须为开发实现不同的捆绑，另一边是托管应用程序( shell)。

当我们想到Iframe (使用友好的Iframe)解决方案时，我们想象出所有子应用程序之间的完全分离，并且倾向于认为这是一种更适合我们的方法。

使用Iframes有什么缺陷吗？

Answer 1

由于您的问题有点宽泛，我只会回答您对Iframes的使用的询问，因为就体系结构提供建议是毫无意义的，而不知道具体情况(目标组?移动?KPI是什么？)(性能、初始负载、开发成本、可重用性、.)

Iframes很适合“完全”隔离(代码+样式)，没有其他方法会给您这样的效果，但是由于这一点，它们有一个的缺点：

• 在iframes之间共享数据需要在外部和内部SPA中进行编排，这需要设置额外的安全措施(因为每个SPA都是公开的)。
• 仅当内部空间位于相同的域中，并且需要额外的JS代码时，才能使用外部空间的内部空间样式。
• 如果内部SPAs与外部SPAs位于相同的域中，则共享cookie只起作用。
• 就性能而言，每个Iframe都需要自己加载所有内容；重用资产、库等非常困难，并且涉及到对每个SPA工具的干预。

通常，如果您控制下的一切都采用了一个真正的微前端方法，那么它是比Iframes更好的解决方案。

Answer 2

你可以试试PuzzleJs。它被设计成用于网关和店面的微前端体系结构的框架解决方案。它正被用于生产我们的高流量电子商务网站。你真该去看看。

它实际上涵盖了几乎所有的需求。

• 独立部署
• 独立源代码
• 独立技术

关于iframe解决方案，可能很难管理诸如CORS和与其他iframe的沟通。

但微前沿解决方案仍不完善。当你真正投入到其中时，会有很多复杂的事情发生。

有些资产将尝试在全局范围内声明相同的变量，有时会有不同的版本会导致错误。这样团队就不会完全独立于彼此。

日志记录和监控变得非常困难。像新文物这样的工具会对你有帮助，但这还不够。您应该实现自定义监视和错误报告工具。

保持应用程序的对接和自动规模友好是非常重要的。有了这个体系结构，如果你有4个网关和一个店面，那就很棘手了。

实现微前端架构的初始成本相当高。您应该仔细考虑您的时间和开发人员资源。

表现是最重要的。您不希望多次下载react或其他库，因为多个团队都在使用它们。您应该实现DllPluginn以删除重复代码。这会让一切变得更艰难。

还有很多其他的问题我都记不起来了。如果你没有50多个开发人员在同一个店面项目上工作，那么微前端就是一个过分的决定。

Answer 3

我们目前正致力于单一水疗框架的完全相同的工作。我们得出了和你们一样的结论。对我们来说，一个主要的问题是儿童应用程序的翻译，因为至少我们无法找到将它们绑定到子应用程序的方法。其他资产，如样式，也是一个问题。

我的建议是等待角元，因为框架不是设计用于微前端风格的。