angular搭建前端框架，微前端如何改变

angular搭建前端框架，微前端如何改变在架构微前端中，最大的挑战之一就是数据共享。数据可以有不同的类型，如状态，UI 组件，或工具函数。确保你的微应用没有包含任何数据存储状态，并且必须将其分离到一个可共享的数据层。你可以想象它类似于前端-后端通信，其中前端是微应用，后端（数据层）是可共享的库。此外，UI 组件和实用工具也将属于同一个 Bucket，作为可重用的共享库。这个理念与单体仓库（monirepo）原理有着密切的重叠。它通过共享数据确保了应用程序之间的一致性。有什么方法可以实现微前端架构，有两个可能的途径：独立部署。由于每个微应用被托管在单独的域中，因此它们都必须单独部署。这会迫使你构建多个管道，这有时可能是个挑战。首先，你必须注意顺序，以防一些微应用共享共同的依赖关系、库、组件和工具。此外，一定要保证每个管道都尽可能地解耦。这样就可以并行运行，并且可以大大加快构建的速度。解耦。微应用必须尽可能地解耦。理想情况下，它们之

前言

为了扩展产品的规模，每一家组织在成长的过程中都要面对一系列的挑战：团队重组，选择正确的技术栈，项目之间的不一致性，以及容错性。在现代世界中，我们会利用微服务来解耦应用程序。这在服务器端是完全可行的，但在前端应该如何操作？在此，微前端（Micro Frontend）就出现了，这类似于微服务，但它并不是拥有一个组件，而是拥有整个业务子域。让我们来看一下，它有什么好处，它又会如何改变 Angular 的未来。

为什么需要微前端？

微前端：是将单个组件或页面托管在独立的域中，并与主要的 shell 应用（宿主应用程序）整合的一种客户端架构设计。每一个微应用都有一个完整的业务子域，并且具有下列特征：

归一支团队拥有。这并不表示只有一支团队会负责修复所有 bug。而是意味着，每个子域都有一个专门的团队，他们具备业务逻辑和技术栈方面的知识。隔离业务的一部分带来了好处，而个别员工的离职并不会对公司的产品和业务造成任何影响。如果你对业务子域有什么疑问，你可以随时与团队联系，而非个人。团队里的每一个成员都要把自己的知识片段通过文档和知识共享会议传达给其他人。

独立实现。拥有微应用的团队在选择技术栈方面拥有完全的自由。它可以是是一个不同的框架，编码实践或架构。尽管自由度越高，灵活性越多，但我们还是要和拥有另一个微应用的其他团队保持一致，至少是在框架的选择上。这样，它可以简化工程师们在团队之间的过渡，并且使共享和集成具有可重用的小部件的库成为可能。

独立部署。由于每个微应用被托管在单独的域中，因此它们都必须单独部署。这会迫使你构建多个管道，这有时可能是个挑战。首先，你必须注意顺序，以防一些微应用共享共同的依赖关系、库、组件和工具。此外，一定要保证每个管道都尽可能地解耦。这样就可以并行运行，并且可以大大加快构建的速度。

解耦。微应用必须尽可能地解耦。理想情况下，它们之间不应该存在依赖关系。它们只能通过共享库来共享数据，如状态、UI 小部件、接口和工具帮助。这一部分需要在架构设计阶段进行额外的工作，以创建合适的抽象。另一方面，重要的是要找到平衡点，不要过度设计。

容错性。微前端架构最大的优点就是可靠性。即使其中一个微应用失效，其他的也能正常工作。这对拥有多个大型独立功能的大型 Web 应用十分重要。让我们想象一下 Facebook，如果其中一个功能，如群组，被删除后，用户仍然还能够与朋友聊天。

健壮的微前端架构

有什么方法可以实现微前端架构，有两个可能的途径：

• 微前端作为一个组件。在这种情况下，微应用更加细化。它作为一个小部件，可以在各种应用中重复使用。这种方法的问题在于，它让微应用之间的耦合变得更加紧密。创建一个合适的抽象可能会很复杂，而且很容易削弱微前端架构的优势。
• 微前端作为一个页面。通过这种方法，我们就可以为每一个微应用提供一个单独的页面。相对于以前的方法，这使得我们可以避免父子之间的紧密依赖关系。所以，这是实现微前端架构最常用的方法。

微应用间共享数据的方法

在架构微前端中，最大的挑战之一就是数据共享。数据可以有不同的类型，如状态，UI 组件，或工具函数。确保你的微应用没有包含任何数据存储状态，并且必须将其分离到一个可共享的数据层。你可以想象它类似于前端-后端通信，其中前端是微应用，后端（数据层）是可共享的库。此外，UI 组件和实用工具也将属于同一个 Bucket，作为可重用的共享库。这个理念与单体仓库（monirepo）原理有着密切的重叠。它通过共享数据确保了应用程序之间的一致性。

还有一些我们需要提到的微应用间的通信方式。首先，我们可以利用浏览器的存储功能。可以是 localStorage、sessionStorage、用于存储会话数据或用户元数据的 Cookie，也可以是 indexedDB 中一些更复杂的数据结构。除了这些，你还可以简单地通过路由器的查询参数在微应用之间进行数据传输。

为什么是 Angular？

Angular 提供了已定义的架构，与单体仓库原理和微前端的最佳实践相一致。

高级架构分为三个主要部分：工作区、项目和库。通过对 Angular 工作区的初始化，我们生成了一个单体仓库应用的骨架，并进一步包括了项目和库。每个项目都可以是一个具有单独入口点的微应用，并且可以具有灵活和可定制的架构。而另一方面，库可以在项目之间共享可重用的数据，它可以是数据层、UI 组件和其他工具函数。

Angular 模块是主要的构建模块。它们将整个功能、组件集或页面及其依赖关系进行封装。这是将我们的微前端应用包起来的绝佳选择。

路由特性是 Angular 开箱即有的，无需安装外部包。它提供了微应用间保持页面转换所需的所有功能。路由出口可以让你配置 shell 应用，托管到微应用的每个页面的导航。你可以选择哪个路由将加载哪一种 Angular 模块。

最后，通过使用惰性加载，当有需要时，可以加载 Angular 模块，从而减少了应用的包大小，加速了页面的加载速度。Angular 在路由和惰性加载模块之间有一个原生的整合。唯一的局限性就是在编译时会加载，但我们需要的是将这个模块在运行时动态地加载。我们很快就会告诉你如何做到这一点。

怎样构建？

好的，我们回顾了微前端的最佳实践，并了解了 Angular 是怎样适合实现这种架构的。还有几个不确定的区域。

首先是如何实时动态地加载模块。这个问题可以通过 webpack 提供的 Module Federation 插件来轻松解决。它支持本地和远程模块独立地、异步地构建，这对我们的情况来说是最理想的。

第二个问题就是我们如何将所有这些资源整合起来，创建一个可行的原型，并且可以对其进行迭代。最快的方法是使用 NX CLI，它将为我们生成所有的模板。为了了解更多，请查看《如何使用 NX 命令行，用 angular、NgRx 状态共享来构建微型前端》（how to build micro frontend with angular NgRx state sharing using NX command line）的分步教程。

结语

我们发现，微前端架构与 Angular 是紧密兼容的。有多种工具可以将它们结合起来，比如 Module Federation 和 NX monorepos。我们只能猜测，未来的 Angular 版本会不会从一开始就支持微前端架构。请看下面的文章，Angular 14 会不会支持微前端：

《Angular 14 在 2022 年会有什么期待：微前端会到来吗？》（What to Expect from Angular 14 in 2022: Is Micro Frontend Coming?）

这可能取决于社区，此外，由于实现工作已经大幅减少，所以在将来，它很有可能会更加流行。

原文链接：

https://itnext.io/how-micro-frontend-changes-the-future-of-angular-bb4deb2cfdad