微型前端应用 - 建立独立的前端团队
意图
比起展示构建微前端的代码，这篇文章更关注于微前端背后的理念。它让你了解核心思想和当前围绕它的解决方案。
当我开始构建前端应用程序时，它只是Javascript，jQuery还处于早期阶段。构建一个前端应用程序只是有一堆HTML（准确地说，在我的例子中，它是PHP），`
快进到现在，我们可以建立一个复杂的前端应用程序，称它为单页，服务器端渲染，等等，HTML住在Javascript里面，用几个`npm`或`yarn`命令，你就有一个运行中的前端应用程序了!
问题
当然，我们正处在一个更好的地方。但是，新的问题也随之而来。我曾亲自在整个堆栈中端对端工作。在后端，疯狂的API世界，驱动着核心业务逻辑，开始时非常简单。到现在，已经有超过几十个跨技术的框架，让你开始快速构建后端应用。
开始时，这将是有帮助的。一旦你的应用程序开始增长，你的团队开始得到更多的人手，和更多的功能，你的后端应用程序增长到一个水平，它将成为管理的噩梦。
让我们举个例子。你正在建立一个电子商务应用程序。你开始有两个技术团队成员。在一个月的时间里，两个人都在工作，并把它带到了现场。庆祝的时刻!你开始收到订单。棒极了!
作为企业的所有者，你会计划扩大业务，这与应用程序本身的功能和范围成正比。仅仅有两个人在工作是不够的，你要雇用更多的人，不一会儿，你就会有30个成员的团队。
如果你有管理人和工作的经验，你会明白分配工作对团队达到目标的重要性。这一点同样适用于此。你需要一个更好的方法来分解工作和分配工作。最好的方法是将技术团队分成若干个子团队，每个团队负责业务的一个部分。因此，你会有一个库存团队，订单团队，履行团队，等等。
每个团队都拥有自己的后端应用程序，它的代码托管方式，它的标准，它的发布周期，以及其他。这里演变出单体的解决方案
微服务
顺便说一下，这不是什么新东西。自从人们开始采用微服务以来，已经有相当一段时间了。人们开始反对微服务，因为它们有缺点。不管怎样，让我们不要关注这个话题，虽然我相信这是因为微服务的执行力差。
简而言之，我们上面讨论的每个团队都会有一个后端应用程序，它将有API供其他团队与之互动。使用什么技术、在哪里托管代码、依赖关系、数据存储等，都是该团队的意愿。直到API到位时，实现在全局层面上并不重要。
这使得团队独立，让他们按照自己的条件和节奏工作。关于微服务，我就不说了，否则会变得很冗长。退一步讲，这种独立团队的想法是如此美丽，在现实中也是有意义的。为什么它只适用于后端应用程序？为什么不把前端团队也包括在内呢？
微型前端
为什么要有一个单一的前端应用程序，不管是React、Vue、Angular还是Svelte？为什么整个代码都要放在同一个仓库里？为什么每个人都要使用相同的框架？为什么当应用程序的执行部分出现错误时，部署管道要被阻断？
换句话说，就是要让前端的应用程序具有功能性。要实现这一点可能并不像听起来那么容易。让我们检查一下这种设置的几个问题
管理一个Javascript的前端应用程序越来越难了，因为有那么多的解决方案，那么多的npm包和版本。管理多个前端项目肯定是不容易的。任何解决方案
- 我们设置了多个前端应用程序，每个都可以独立构建和部署，这将是一个方便的解决方案。
- 我们可能希望有一些共同的组件，这些组件将在各子项目之间共享。
这就是所谓的monorepo。一个代码库有多个子应用，代码可以共享，每个子应用可以单独构建。这就解决了构建多个前端应用的问题。
微型前端的使用
我们的问题并不是只用一个monorepo设置就能解决的。我们需要更多。如果你看到上面的图片，想象一下我们正在构建浏览产品页面。我们会显示
- 要购买的产品列表
- 购物车中的商品
- 该页面本身
如果你把它拆开，有2个团队参与其中，分别是库存和购物车团队。现在的问题是，页面上如何呈现由Inventory团队构建的产品部分，以及由Cart团队构建的购物车部分？他们是完全不同的应用程序，服务于不同的主机。
微型前端之间的安装和通信
容器应用如何渲染子应用？子应用程序如何与容器应用程序通信？应用程序的数据/状态是如何交换的？如果你观察上面的图片，"添加到购物车 "按钮是来自Cart团队。如何渲染儿童应用程序的多种类型的屏幕？有很多问题需要回答。让我们逐一来看看
安装
有一个容器应用和一个从远程主机提供服务的子应用。我们的要求是，将儿童应用程序安装到容器应用程序上。这应该是与框架无关的。一旦它被挂载，它就应该与容器应用无缝地工作和融合。在用户界面和控制部分方面都是如此。
数据共享和通信
最简单的要求是，子应用程序需要知道谁是登录的用户。在容器和子应用程序之间应该有一个共享的数据存储。它也应该是反应式的。容器和子应用程序之间也应该有一个通信渠道。
正如我在上面所说的，从概念的角度来看，这看起来很有趣，但实施起来并不容易。强烈不建议小团队使用这种方法。如果执行得不好，不仅不能解决问题，反而会产生更多的问题。
我只想讨论这个概念，因为可能会有多种实施方式和变化，但想法是一样的。因此，如果我们理解了这个概念，我们就可以工作和实施对我们有用的东西。
如果你想看到它的实际效果，我推荐一些资源
如果你喜欢这篇文章，请在这里和Twitter上关注我 -@pramodk73。我一直在发布关于软件工程、SaaS和公共建设的信息。欢呼吧!
什么和为什么是微型前端？最初发表在Dev Genius的Medium上，在那里人们通过强调和回应这个故事来继续对话。
