微前端规则

　　我总是想知道大型Web应用程序是如何建造的！我发现了秘密的秘密，它成为我的激情。经历在规模上使用微型前端的优势和痛苦后，我决定记录这段旅程并分享一些“最佳实践”。

　　这是在设计遵循微前端模式的应用程序时的最佳实践的自由练习列表。应检查每个“规则”，其福利/缺陷针对您的特定用例评估。

　　微前端之间的零耦合

　　为了实现这种架构的好处，应尽可能避免意外耦合;这将解锁微前端模式必须提供的灵活性和可扩展性以及通过允许占用申请部分的升级或将来的完整重写来替换您的应用程序的未来证明。

　　每个微前端应该能够在隔离或容器应用中呈现。所需的数据应由每个微前端加载并避免数据瀑布。

　　做：

　　可以在不影响其他微前端的情况下交换的共享库。?加载所需的所有数据呈现。

　　不要：

　　在不同的微前端具有集中存储/共享数据。共享积极开发的库。单独的代码基础

　　每个微前端都应具有自己的代码库，并且选择的版本控制不应对项目开发或部署的方式产生任何影响。在单一的单一或单独的存储库下拥有所有项目都很好。

　　做：

　　使用单一代码仓 monorepos。使用单个 repos。每个微前端应独立部署

　　每个微型前端都有它自己的CI / CD管道，并且能够在没有其他微前端的任何依赖项的情况下部署到生产。应该避免的常见的反模式是“地狱的部署队列”，其中不同的微前端如此紧密地耦合，它们需要以特定顺序部署，以避免打破应用程序。

　　做：

　　具有单独的CI / CD管道。按需发布。

　　不要：

　　有发布时间表。具有允许以前版本的增量/顺序部署。微前端应独立测试

　　因为需要单独的微前端以及容器应用程序内部呈现，因此还可以使用单位和整个方案的集成测试测试它们是有意义的。

　　做：

　　为隔离的每个微前端渲染具有单位和集成测试。在容器应用程序中运行微前端渲染的集成测试作为端到端测试的一部分。微前端应该是有版本的

　　当一个新的微前端被部署到生产时，不应删除以前的版本，并且应该使用语义版本或类似的版本号标记新版本。由容器应用程序决定要使用（管理）的特定微前端或始终使用最新版本（Evergreen）的特定版本。

　　做：

　　使用语义版本化。使用特定版本或“最新”。

　　不要：

　　需要全局部署更改版本。删除以前的版本。最小的沟通

　　微前端之间的通信应尽可能最小，简单，避免尽可能多的全球状态和框架特定的解决方案。

　　如果两个或更多的微前端共享大量消息以提供其最小功能，它们可能太紧密耦合，并且它们可以共享类似的足够的目的，即它们应该被认为将它们集成到一个中。

　　做：

　　保持信息小而简单。如果可能的话，避免有状态和通信框架。

　　不要：

　　股东。有不必要的沟通。CSS应该是范围

　　来自一个微前端的CSS不应影响其它微前端。

　　做：

　　为您的CSS定义范围。使用CSS-IN-JS或命名法库（如CSS模块）。

　　不要：

　　使用全局CSS。最终建议书尝试创建自治团队。尝试安排围绕业务功能的微前端。可重用性是一个很好的“副作用”而不是目标。不要强制这种架构风格，因为它是“新”。您不需要多个JavaScript框架。您不需要“微前端框架”。微前端不必是“Micro”。