构建时微前端的案例

微前端彻底改变了我们构建和管理现代 Web 应用的方式。通过将单体前端分解为更小、独立开发和交付的单元，团队可以更有效地协作、采用多种技术并扩展开发流程。

虽然运行时微前端经常因其动态加载和独立性而备受关注，但构建时微前端值得仔细研究。它们在性能、一致性和模块化方面具有显著优势——这些品质可以成就或毁掉复杂的应用程序。

两种流行工具，鼓励我们重新思考构建时微前端集成。这些工具通过展示构建时集成如何实现显著的性能、一致性和模块化改进，挑战了关于单一存储库和多存储库的传统假设。

通过使用独立的、具有高级依赖管理的组件驱动开发，Bit 和 Ripple CI 为团队如何有效协作和维护分布式前端系统提供了新的视角。

什么是构建时微前端？

构建时微前端涉及在​​构建过程中组装应用程序的不同部分，而不是在运行时动态组装。组件在部署期间独立开发、版本控制并组合成统一的应用程序。Bit 等工具通过使团队能够创建易于集成的模块化、可重复使用的组件来促进这种方法。

Node 包和微前端之间的区别

出现了一个常见的问题：考虑到包的广泛使用，每个 JavaScript 项目都可以被视为构建时微前端吗？

随着 Bit 组件的出现，这个问题变得更加微妙，这进一步模糊了界限。虽然 Bit 组件可以作为标准 Node 包安装，但它们提供的功能远不止这些。每个 Bit 组件都可以作为独立项目进行版本控制、维护和交付，从而无需专用存储库。版本控制是独立处理的，开发不需要独特的环境或构建管道 - Bit 提供了可重复使用的预配置设置，无论在何处编辑组件，都可以无缝运行。

答案很简单，不是——JavaScript 包（包括 Bit 组件）和微前端尽管在模块化方面有共同的基础，但用途却截然不同。以下是它们的区别：

本质上，虽然 Node 软件包和微前端都强调模块化，但它们的范围和目标却截然不同。Node 软件包注重开发过程中的可重用性，而微前端则优先考虑应用程序用户界面的自主性和可扩展性。

构建时 MFE：示例

“永恒的火星”应用程序邀请用户注册参加单程火星之旅。

由构建时 MFE 组成的“永恒火星”应用程序

该应用由 Bit 组件组成，从最基本的 UI 组件和实用功能到完整的 MFE，可集成到单个应用程序中。这些组件在 Bit Platform 上访问受控的集合中共享，称为“范围”。其中一些范围（如预订范围）包含 MFE（预订应用），而其他范围（如设计范围）仅包含共享依赖项（此应用的设计系统）。

在 Bit 平台上访问控制范围内共享的基本组件和 MFE：https://bit.cloud/cosmo-cruises

虽然 Bit 组件没有可以编辑和发布的存储库，但开发人员通常更喜欢使用 git 存储库和他们习惯的协作工具来维护它们。

Bit Platform 允许跨存储库共享和使用模块，而 Ripple CI 允许将更改从一个存储库中维护的一个组件传播到其他存储库中维护的其他依赖组件（甚至根本没有存储库）。

为什么选择构建时集成？

1. 性能优化

性能是任何成功的 Web 应用程序的基石。构建时微前端在这方面表现出色，消除了与动态加载多个模块相关的运行时开销。由于所有集成都在构建过程中进行，因此用户体验到更快的加载时间和更流畅的交互。

例如，构建时集成可确保共享依赖项已预先捆绑和优化，而不是依赖于会减慢初始渲染速度的运行时依赖项。这可减少负载并降低延迟，尤其适用于流量大或性能要求严格的应用程序。

这并不意味着整个应用程序应该始终捆绑为单个块。在正确的地方使用时，动态加载依赖项可以成为更高效的选项。代码分割通常是一种明智的策略，但值得注意的是，即使这样，结果也会是更优化的块，并且运行时错误的可能性更小。

2. 增强一致性

微前端架构面临的最大挑战之一是保持应用程序不同部分的一致性。运行时微前端经常导致版本不匹配或样式不一致，因为团队独立工作并在不同时间部署更新。

构建时微前端通过在构建阶段强制执行一致的依赖关系和样式来解决此问题。Bit 等工具可以集中管理共享组件，确保应用程序的所有部分都遵循相同的设计系统和功能标准。结果如何？即使不同的团队负责应用程序的各个部分，也能获得无缝衔接的统一用户体验。

3.简化调试和维护

调试运行时集成应用程序就像大海捞针。由于多个微前端动态交互，追溯问题根源变得十分复杂。

构建时微前端简化了此过程。由于组件在构建期间组装和测试，因此可以尽早发现和解决问题。Ripple CI 等工具通过定位受影响的组件以加快构建速度并在投入生产之前捕获依赖冲突，进一步简化了此工作流程。

4.通过模块化实现可扩展性

随着应用程序的增长，管理它们的复杂性也在增加。构建时微前端通过促进模块化在大型项目中蓬勃发展。每个组件都可以独立进行版本控制和更新，从而降低了重大更改的风险。

此外，借助 Bit 等平台，团队可以在多存储库设置中开发组件，甚至无需使用传统存储库。这种灵活性允许高效扩展，而不受严格的开发结构的束缚。

5. 集中式状态和通信

使用构建时微前端可以更直接地管理全局状态、路由和共享服务。通过在构建阶段集中关注这些问题，开发人员可以确保应用程序的所有部分都使用相同的状态管理和通信模式。

例如，在构建过程中，身份验证或主题的共享上下文可以包装在各个组件中。这可确保应用程序的每个部分都一致运行，避免运行时差异。

关于构建时微前端的误解

人们普遍误以为构建时微前端需要 monorepo 设置。虽然 monorepos 是一种选择，但并非强制性的。Bit 等工具使在 polyrepo 设置中甚至独立于存储库维护构建时微前端成为可能。这种灵活性使团队能够选择最适合其工作流程的结构。

另一个误解是，构建时微前端的动态性不如运行时微前端。虽然运行时解决方案在动态更新方面表现出色，但构建时方法可以通过 Ripple CI 等工具实现类似的敏捷性，这些工具可以自动更新依赖项并确保跨组件的无缝集成。

结论

虽然运行时微前端通常会获得更多关注，但构建时微前端为可扩展的高性能应用程序提供了令人信服的案例。它们能够优化性能、确保一致性并简化维护，使其成为许多团队的绝佳选择。

通过利用和 [**Ripple CI**] 等工具，开发人员可以充分发挥构建时微前端的潜力，创建不仅模块化、可维护，而且高效、有凝聚力的应用程序。现在是时候让构建时集成受到应有的关注，并拥抱分布式前端既强大又用户友好的未来了。