考虑使用微前端的10个理由

了解和探索微前端
考虑使用微前端的10个理由文章插图
> Photo by HENCE THE BOOM on Unsplash
现代Web应用程序变得越来越大 , 越来越复杂 , 有时由不同的团队来管理 。您的应用程序可能具有由不同团队开发的功能 , 并且您希望在交付整个应用程序之前仅将某些功能发布到生产环境中 。如果您有一个仓库 , 您如何管理不同的团队 , 不同的发布时间表?
【考虑使用微前端的10个理由】这些复杂的应用程序大多数都生活在客户端 , 这使得维护变得更加困难 。这个整体式的大脂肪应用程序还存在其他一些问题 。在这篇文章中 , 我们应该考虑微观前端的原因有哪些?
1.应用很小第一个原因是应用程序变小了 , 您不必下载大型代码库 , 而只需要等待10分钟即可安装所有依赖项 。想象一下 , 您加入了一家公司并第一次克隆了存储库 , 而您必须等待15分钟才能下载依赖项并编译项目 。当您查看源代码时 , 有成千上万的组件被编写 , 您甚至都不知道在哪里寻找或在哪里进行更改等 。 如果您的应用程序足够小 , 则可以更快 , 更轻松地浏览应用程序 。
2.应用是独立的由于所有应用程序都是分开划分和开发的 , 因此它们彼此独立 。当您拥有一个整体应用程序时 , 您有太多彼此依赖的模块和组件 , 从而导致在哪里进行更改或在哪里寻找外观等方面的困惑 。 设想一个场景 , 您必须在现有的整体应用程序中进行一些更改 , 并且 5个不同的团队为此工作 。有时 , 您每次必须召开一次会议 , 从所有团队中查找信息大约需要2周的时间 。如果应用程序具有明确定义的边界并允许一个专门的团队专注于此 , 通常可以节省大量时间 。
3.应用程序更易于理解应用程序较小 , 由一个团队开发 , 因此更易于理解 。由于这些应用程序具有明确的界限 , 并且由一个团队开发 , 因此它们通常遵循一致的样式指南 , 这使它更易于理解 。对于大型应用程序 , 有几个团队在处理它 , 而他们通常不遵循一致的样式指南 。您甚至可以定义一个好的项目结构 , 因为用于项目的组件或服务数量很少 。
4.应用程序更易于开发和部署由于这些应用程序的性质很小 , 并且由一个团队开发 , 因此非常容易开发和部署 。我们甚至可以独立部署 。当您在Jenkins上拥有大型应用程序的构建管道时 , 由于拥有成千上万的组件 , 因此需要等待20至40分钟才能下载并编译该项目 。当您为每个微型应用程序定义单独的管道时 , 使用微型前端可以大大减少这些构建时间 。
5.应用程序更易于测试我们必须为大型应用程序编写成千上万的单元测试 , 并且要花很多时间才能运行 。这会使我们的部署过程变慢 。当涉及到微型前端时 , 每个应用程序只有很少的单元测试 , 并执行自己的单元测试 , 并且可以独立运行 。
6.应用程序开发变得更快由于有独立的团队 , 整个开发变得更快 , 更容易 。
7. CI / CD变得更容易每个应用程序都可以集成和单独部署 , 这使得CI / CD的过程变得更加容易 。当我们修复应用程序或引入新功能时 , 我们不必担心整个应用程序 , 因为所有功能都是独立的 。
8.独立的堆栈和版本我们可以为每个应用选择自己的堆栈 , 但是这种情况很少发生 , 但是我们可以在同一堆栈中使用不同的版本 。例如 , 某些团队具有灵活性和时间来引入和测试同一堆栈的较新版本 。例如 , React很好 , 可以灵活地完成任务 , 而Angular可以很好地满足其他要求 , 您可以根据自己的需要选择框架 , 而不必依赖以前的开发人员或以前的团队就开始使用它 。相同适用于同一框架的不同版本 。
9.没有共享代码在大型应用程序中 , 我们倾向于跨功能共享代码 , 但是这种扩展性不好 , 并且随着应用程序越来越大 , 会引入许多错误和相互依赖性 。这不适用于微型前端 , 因为除非它是愚蠢的组件 , 否则我们不会共享代码 。我们可能会分享信息
10.可以轻松更改架构 , 而无需触及旧架构有时我们必须扩展旧的体系结构 , 但是我们可能没有开发人员来实现或扩展该体系结构 。借助微型前端方法 , 我们可以开发具有最新堆栈的新功能并独立交付 。如果要扩展已有20年的现有应用程序 , 很难找到开发人员 , 因为您必须使用新技术来实现整个应用程序 , 或者可以借助微前端方法进行扩展 。
结论我知道微前端并不能解决所有问题 , 但是它为您提供了足够的理由和灵活性来开始考虑这些问题 。