微型前端使您的团队可以独立管理和部署前端的一小部分。对于您的组织来说，这种体系结构增加的复杂性值得吗？
在过去的几年中，随着小型分布式后端Web服务的兴起，人们现在开始谈论在前端执行相同的操作就不足为奇了。“微型前端”是一个术语，最早出现于2016年，用于描述小型，解耦的前端Web应用程序，这些应用程序可以协同工作以构成完整的应用程序。
随着大型团队脱离整体代码库，他们将前端代码（显示和UI）和后端代码（数据库，授权和业务逻辑）分开。随着复杂性和团队规模的增长，许多公司转向微服务，将后端代码库分为较小的，可独立部署的部分。虽然没有完美的架构，但许多公司已成功采用微服务来降低复杂性并提高交付速度。
微前端使用与微服务相同的概念来改进前端代码库。像React，Angular和Vue这样的框架的出现和广泛采用刺激了前端处理的复杂性和业务逻辑的增长。尽管微型前端仍然需要良好的体系结构，并且经常使用这些较重的框架，但是能够以小块形式独立管理和部署前端的功能吸引了大型工程组织。
微型前端是什么样的？
微型前端的想法是通过产品功能将用户界面分成多个部分，并使每个部分成为可独立部署的前端代码库。尽管分解代码的部门和方法各不相同，但可以想象一个具体的示例。
如果您运行电子商务应用程序，则您的产品详细信息页面可能具有导航栏，登录按钮，用户购物车的摘要，买家评论以及有关产品和图像的一些元数据。在典型的前端应用程序中，您可能会将所有这些部分划分为多个组件，但都位于同一代码库中。在微型前端架构中，您可以将应用程序分为五个不同的代码库，每个代码库均由负责一项特定功能的团队拥有。
这种架构将使评论小组可以在星期一部署新的审查界面，购物车小组可以在星期二部署购物车更新，客户小组可以在星期三解决登录错误-所有这些都不会影响网站上的核心产品详细信息页。
虽然新颖，但这种结构引入了一些复杂性。更多的应用程序意味着更多的代码和更多的部署。在本文的其余部分中，我们将介绍微型前端的一些优点和缺点。我们将了解工程师采用这种体系结构时需要做出的决策，并帮助您确定它是否适合您的组织。
为什么要使用微型前端？
我已经开始暗示开发人员可能会采用微型前端的一些原因，但让我们来具体说明一下。
- 强边界
每个软件开发人员在计划新项目时都会考虑关注点的分离。虽然微前端不是组织良好的前端代码库的要求，但它们可以促进Web应用程序中职责之间的明确区分。
- 小型代码库
较小的代码库本质上更容易推理。假设您的边界是明确定义的，那么团队可能会更喜欢小型代码库而不是大型代码库。也就是说，设置跨越边界的自动化和调试错误可能是微前端面临的新挑战。
- 较小的部署
随着前端的增长，诸如更新缓存或清除CDN之类的简单操作可能会极大地影响性能。微型前端使您可以对代码库的各个部分进行小的更改，而不必被迫一次完成整个过程的更新。这些较小的更改还限制了错误的范围，因为它们可能仅影响与之交互的代码段。
- 自治团队
最后，应用程序中的每个微前端都可以由一个团队进行管理，该团队可以选择最适合其需求的框架，库和设计模式。这些小型，自治的团队在每个决策中面临的瓶颈和签署减少，此外，这种结构使组织能够在不重写整个前端的情况下尝试使用新工具。
微型前端的缺点
每种架构风格都需要权衡取舍，微型前端也是如此。尽管它们解决了一些棘手的问题（尤其是对于大型企业软件团队而言），但同时也带来了一系列新问题。如果您使用了后端微服务，则可能已经意识到了这些折衷，但是值得注意。
- 重复的依存关系
如果您想象有三个前端应用程序都加载了自己的前端框架，那么您会发现重复的依赖关系能够以多快的速度降低您的应用程序速度。与后端微服务相比，与前端微服务相比，这甚至是更多的问题，因为每个依赖项都必须通过Internet传递给用户，而不是简单地在服务器上进行编译。
- 孤立团队
因为微前端鼓励元素之间的业务案例边界，所以它们可能会导致不良的“我们与他们”文化。如果允许团队使用不同的前端框架或设计模式，那么当开发人员想要从一个单元转移到另一个单元时，也可能会引入不必要的摩擦。
- 刚性边界
最后，将您的边界完全分开的应用程序使它们以后很难移动。在一个大型的，已建立的应用程序中，这可能是一件好事，但它可能不必要地减慢了快速变化的新应用程序的开发速度。
采用微前端之前要做出的决定
如果您权衡了利弊，并决定值得投资微前端架构，那么该是时候考虑实现细节的时候了。由于微型前端是新的，因此必须重新考虑传统的整体式前端中长期解决的许多问题。
- 用户界面一致性
例如，您必须决定如何标准化前端的样式。您会为每个微型前端加载单个样式库还是单个样式库？您将有一个确保一致性的中央设计师吗？如果可以，那么如何防止它们成为瓶颈？您将如何与其他微型前端团队交流变更或新样式？
一种解决方案是使用像Kendo UI这样的标准UI库，该库为开发人员提供了针对常见样式元素的预构建解决方案。尽管您仍然必须决定如何以及在何处加载这些组件，但是拥有一个集中的资源可以让每个团队减少设计决策。
- 集成
采用微型前端时，另一个有趣的挑战是确定如何以及何时集成它们。在某些时候，所有较小的应用程序都必须编译并作为单个可用应用程序提供给用户。可以使用标准工具（如Nginx）或专用工具（如Ara）在服务器上完成此组合。可以在构建时通过将前端作为单独的程序包编译到Shell应用程序中来完成。可以使用iFrame或专用工具（如single-spa）在前端完成此操作。
这里没有正确的答案，但是您做出决定的含义可能很广泛。集成会影响您测试，交付和构建应用程序的方式，因此在开始之前请多加考虑。
- 共享资料
最后，考虑组件之间的共享数据和通信。您是否需要重复API调用以聚合数据，或者您的微前端会有一个共享状态？他们将如何与所需的后端服务连接？如何将一个微前端的更改传播到另一微前端？您将如何处理身份验证数据？
在具有不同代码库的前端之间共享数据不一定很容易。随着您的应用程序的发展，这将成为维护和开发中越来越具有挑战性的方面。
结论
微型前端的最佳做法仍在不断发展，但是很显然，它们可以解决一些难题，特别是对于大型团队而言。在前端开发中，能够独立部署应用程序的各个部分，强制执行边界并为当前域选择最佳技术的能力是独一无二的。假设您的团队具有解决微型前端所带来的一些挑战的技术专长，那么这种模式可能值得投资。