微前端架构建议

Question

我们希望在单个页面应用程序下提供多个Web应用程序。 我们正在寻找一个可以使用的微前端架构/框架。 正如我们所看到的，这些是我们实施的选择：

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

当前状态是一个整体FE应用程序，它将其他子应用程序作为内部第三方程序包使用。 这种方法对我们来说是不可扩展的，因为托管应用程序正在一起构建所有产品，并没有真正分离。

我们的要求是微前端的通常要求： 1.独立发展 - 无论其他产品如何，每个团队都可以选择自己的框架并构建自己的产品。

1. 独立部署 - 每个应用程序都可以在生产中升级，无需停机，也不会干扰其他应用程序。

2. 共享组件 - 我们在我们的应用程序中使用Angular4，并且我们已经编写了一个专有的第三方库（共享组件和逻辑），应该在所有产品之间共享，以获得相似的外观。

3. 我们希望能够升级每个应用程序的框架（Angular，RXjs，Typescript等以及我们的专有组件库），而无需关心其他应用程序。

我们尝试使用单一水疗中心框架，但我们遇到了一些问题，如果这对我们来说是正确的方法，或者我们应该尝试不同的方法，我们现在可以自己思考。

我们使用单一水疗中心的问题包括： 1.资产装载是有问题的。 （我们必须将资产文件放在托管应用程序的根文件夹中，并且切换到另一个应用程序时会遇到资产冲突）。 2.我们仍然不知道如何处理所有应用程序的全局样式（我们使用sass进行样式设置，并且必须与每个应用程序的本地样式一起使用） 3.升级角度框架（或所有其他框架）对于一个应用程序是不可能的，它是全部或全部（因为我们有一个角度的实例）。 4.我们必须在托管应用程序（shell）的另一端实现不同的开发捆绑。

当我们考虑Iframe（使用友好的Iframe）解决方案时，我们想象所有子应用程序之间的完全分离，并倾向于认为这对我们来说是更合适的方法。

使用Iframe有任何陷阱吗？

谢谢， 丹尼尔

Answer 1

我想将2¢添加到前端微服务的可能架构解决方案主题中：

1. OpenTable使用的OpenComponents - https://github.com/opentable/oc
2. Zalando的马赛克 - https://www.mosaic9.org/

希望你觉得它们很有用。

Answer 2

由于您的问题涉及范围很广，因此我仅会解决有关iframe使用情况的问题，因为在架构方面向您提供建议是毫无意义的，而不知道具体情况（目标群体，移动设备，KPI是什么？初始负载，开发成本，可重用性，...）

iframe可以很好地实现“完全”隔离（代码+样式），没有其他方法可以做到这一点，但是正因为如此，它们有很多缺点：

• 在iframe之间共享数据需要在外部SPA和内部SPA中进行编排，这涉及设置其他安全措施（因为每个SPA都暴露在外）
• 通过外部SPA设置内部SPA的样式，仅在它们位于同一域并且需要其他JS代码时才有效
• 仅当内部SPA与外部SPA位于同一域时，共享cookie才有效
在性能方面，每个Iframe都需要自行加载所有内容；重用资产，库等非常困难，并且需要干预每个SPA的工具。

通常，如果您要控制所有 ，那么采用真正的微型前端方法是比iframe更好的解决方案。

Answer 3

您可以尝试PuzzleJs。它被设计为网关和店面的微前端架构的框架解决方案。它被用于生产我们的高流量电子商务网站。您应该检查一下。

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

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

---

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

---

但是微前端解决方案仍然不是完美的。当您真正深入研究时，会有很多复杂性。

某些资产将尝试在全局范围内声明相同的变量，有时它们将具有不同的版本，这将导致错误。因此，团队之间不会完全独立。

记录和监视变得异常困难。像New Relic这样的工具会为您提供帮助，但还远远不够。您应该实施自定义监视和错误报告工具。

保持经过docker化和自动扩展友好的应用程序确实很重要。使用这种体系结构，如果您有4个网关和一个店面，可能会很棘手。

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

性能是最重要的。您不想多次下载React或其他库，因为有多个团队正在使用它们。您应该实现DllPluginn来删除重复的代码。它将使所有工作变得更加困难。

还有很多其他我不记得的问题。 如果您从事同一店面项目的开发人员不超过50名，那么微前端是一个过大的决定。

Answer 4

我们目前使用单一spa框架完成同样的工作。我们得出了与你相同的结论。对我们来说，一个主要问题是儿童应用程序的翻译，因为至少我们无法找到将它们捆绑到子应用程序的方法。风格等其他资产也是一个问题。

我的建议是等待angular elements，因为该框架并非设计用于微前端风格。

Answer 5

您可以公开每个应用程序中的Web组件，并在主SPA中聚合/使用它们。所有浏览器都支持Web组件，所有领先的SAP farmeworks（如angular，ember，react，vue）都支持webcomponent。这样，您就不会绑定到任何特定的SPA框架，并且可以在任何地方恢复组件。

Answer 6

您可以将ShadowDom v1.1视为Iframe的替代产品。我最近使用这种技术来工作和部署银行业务应用程序，以隔离父级应用程序的样式（这是具有jsp服务器端模板的有状态应用程序） 但这只会给您样式隔离。

每个子应用程序最好有不同的代码库。这样，您可以独立开发它们，迁移到不同的Angular版本，然后分别部署。 共享组件和专有的第三方库可以作为node_module发布，您可以在其中将其导入每个子应用程序。 （我想您应该具有私有/内部人工存储库设置）

子应用之间的相互通信可以通过localStorate / sessionStorage完成。您可以将它们进一步包装为共享服务，然后再次发布为node_module依赖项。

**设置

yourcompany.com->父应用

yourcompany.com/app1.html->子应用程序1-具有捆绑的js文件和CSS的引导程序 yourcompany.com/app2.php->子应用程序2-具有捆绑的js文件和CSS的引导程序 yourcompany.com/app3.jsp->子应用程序3-具有捆绑的js文件和CSS的引导应用程序

**或使用子域

yourcompany.com->父应用

app.yourcompany.com->子应用程序1

blog.yourcompany.com->子应用程序2

home.yourcompany.com->子应用程序3

Answer 7

我相信我在this thread上的回答将非常有用。但是要进一步澄清

1. 鉴于主应用程序已部署到www.example.com，每个子应用程序都必须通过强制导入来继承全局样式，即

   @import url('https://www.example.com/path/to/global/style.css');
   

2. 对于Web组件，各个子应用程序的样式不可转让。同样，必须强制从基本应用程序继承样式。
3. 由于每个子应用程序都可以独立构建，因此它与语言无关。一个应用程序可能会选择使用Vue，而另一个应用程序会使用Polymer。
4. 使用Web组件与使用iframe相似，只是它更轻巧并且可以附加。

希望有帮助

Answer 8

这个话题已经很老了，但是也许仍然有人会发现以后再阅读答案很有趣，因为它仍然是一个很好的话题。

您在问题中发布的这个软件包-https://github.com/single-spa/single-spa看起来非常好，我们尝试使用它，但是，它有太多特定于框架的内容，这使新工程师的入职变得非常困难。 / p>

我认为首先您需要为应用程序的微前端组成选择方法：

• 构建时组成
• 服务器端组成
• 客户端组成
• 路线组成

我已经尝试通过文章https://medium.com/@danielostapenko/frontend-architecture-in-scale-for-large-organizations-593930ed10cd

中的一些有用链接来描述它们

此外，我真的鼓励您查看Webpack 5提供的Module Federation功能。在微前端世界中工作看起来非常有前途且舒适。