「微前端架构」-Angular风格-第1部分

「微前端架构」-Angular风格-第1部分

它是什么，为什么我需要它?

让我们从why部分开始，当单页面应用程序启动的时候，大多数应用程序都非常小，并且由一个FE团队管理，一切都很好……

随着时间的推移，应用程序变得越来越大，管理它们的团队也越来越大。没有必要过多地讨论拥有大型代码库和大型团队的问题……

“微前端”这个术语最近被频繁使用，它提供了一个类似于微服务的概念，我们可以将单个前端应用程序拆分为微应用程序，这些微应用程序可以加载到用户浏览器上运行的单个容器应用程序中。每个应用程序都可以有自己的代码库，由一个面向业务的团队管理，他们可以独立地测试和部署他们的微应用程序。

(taken from DOM仍然缺乏完整的浏览器支持。

我们的解决方案

在Outbrain，我们一直面临着大多数资深SPA (单应用)所面临的问题，我们有一个庞大的FE应用程序，有一个庞大的团队来管理它，它变得越来越粗糙。看到在野外没有出色的MFE解决方案，我们决定尝试寻找一个我们自己的解决方案，一个可以在我们现有的echo系统上快速实现的解决方案。

我们定义了几个关键点，我们认为任何解决方案都必须应用MFE。

独立模式

每个微应用都应该能够完全独立运行，所以每个负责给定应用的团队都应该能够独立于其他应用运行。

这意味着每个应用程序应该托管在一个单独的代码基上，并且能够在开发人员的计算机上本地运行，以及在开发和测试环境中运行。

部署

可以独立每个服务部署到任何环境包括生产为了让业主团队的自由而不干扰其他团队工作,如果一个bug修复需要部署到生产在周末没有其他团队应该参与。

测试

在每个微应用程序上独立运行测试，这样一个应用程序中的bug很容易识别，不会反映到其他应用程序上。也就是说，有必要进行一些集成测试来检查应用程序之间的接口，并确保它们没有被破坏，这些测试应该由所有团队监控。

一个到多个

我们希望能够多次使用每个微应用程序，一个微应用程序不应该关心它在哪里运行，只知道它的输入和输出。

运行时分离和封装

重要的是，每个应用程序在运行时环境中都要沙箱化，这样应用程序之间就不会相互干扰，这包括CSS封装、JS命名空间和HTML分离。

常见的资源共享

因为我们不想要加载大型模块,如角,lodash和多次CSS样式的应用程序是很重要的微型应用程序能够共享公共资源,也就是说,我们也希望能够允许他们只封装资源相关,或封装在应用程序资源有不同的版本,例如应用程序使用lodash 3和应用程序B想迁移到lodash 4。我们不希望等到所有的应用程序都迁移之后才能升级。

通讯

需要有一种解耦的方式，让应用程序在不真正了解彼此的情况下彼此通信，只需要通过预定义的接口和API。

向后兼容性

由于我们不打算重写庞大的代码库，所以我们需要一些可以插入到当前系统的东西，以及可以由其他团队管理的逐渐独立的部分。

Web组件

最后,任何解决方案我们应该尽可能一致的web组件的概念,尽管它目前只是一个概念,似乎这就是未来是标题,如果将来任何解决方案出现,将自己与未来这将帮助我们采取的解决方案。

第2部分

在接下来的部分中，我将详细介绍我们是如何实现这一目标的，以及我们是如何通过写作来实现这一目标的。

下一部分的内容包括Angular、Webpack和一些美味的加载器。

谢谢大家关注，转发，点赞。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。