咱们如何构建微前端

构建微前端，放慢和扩充咱们的网站开发过程。

请在 bit.dev 查看咱们的微前端的运行状况。

在 比特 ， 咱们为超过 10 万名应用组件的开发者构建工具。咱们的工具帮忙开发者构建、重用和合作独立的组件，以放慢开发速度和进步利用品质。

从第一天起，咱们就开始狗尾续貂地开发本人的工具，同时让组件驱动咱们的架构和开发流程。这样做的一大劣势就是能够享受 微前端 的益处。

微前端是一种将单体前端代码库宰割成更小、更易治理的碎片的形式。因而，前端团队能够享受到与微服务相似的益处：可保护的代码库、自主团队、独立公布和增量降级。

微前端通常被认为是由独立的前端组成，它产生在_运行时，_在服务器或客户端。

尽管运行时的集成有其益处（例如更小的有效载荷），但它们绝不是实现 “ 可独立交付的前端利用组成 ”_的惟一办法（援用 Cam Jackson）。

在咱们看来，这种构建和合作前端利用的新形式，是微前端的外围因素。

通过 正确的组件模型 和正确的工具，任何团队都能够采纳模块化的办法来构建 Web 利用，并享受这些益处。

对咱们来说，在构建时组成前端利用，能够带来两败俱伤的成果 –“ 传统单体 “ 的安全性和健壮性，以及微型前端的简略性和可扩展性。为此，咱们应用了 Bit– 一个有助于使每个组件齐全独立的开源库，以及咱们的云平台 – 它能够让团队高效地合作和整合在一起。

正确的模式，正确的工具

在本文中，我将展现咱们 Bit 公司是如何构建微前端的。我将解释它是如何帮忙咱们实现 解耦代码库 、 齐全自主的团队 、 独立的增量降级 和近 100% 的模块化代码重用 等指标的。心愿你能发现这些分享的常识对你有用。

首先，一个活生生的例子

如果你去 Bit.dev 的主页，你会发现每次你把鼠标悬停在一个组件上时都会产生一些奇怪的事件。

鼠标进入一个组件后，高亮显示就会关上，示意该组件的名称、独立版本以及公布和裸露的范畴。当你滚动时，你会发现整个页面是由不同团队独立构建、版本化和共享的组件组成的，在不同的代码库中，应用不同的构建流程，并且都集成在一起，成为一个具备凝聚力的产品。

你在那里看到的，是咱们团队如何应用 React 和 Bit 等古代组件驱动技术来构建微前端的实在演示。

在这个页面上，你会看到两套组件，由两个团队开发。一个是 “base-ui “ 组件集，由咱们的前端基础设施团队领有。第二套是 “evangelist”，由咱们的营销团队领有。

这两套组件整合在一起，能够疾速组成你所看到的主页，以及其余页面，如【企业页面】(https://bit.dev/enterprise)或【反对页面】(https://bit.dev/support-plans)，甚至能够组成更多的利用。

[

](https://bit.dev/support-plans)

当初咱们能够十分疾速地编写更多的页面

如果你点击组件的范畴，你就能亲眼看到咱们的代码库架构和组织构造。

[

](https://bit.dev/enterprise)

创立一个新的网站须要几个小时而不是几周的工夫

组件的一个范畴叫做 ”base-ui“。这是 Bit.dev 最根本的组件设计零碎，它蕴含了诸如 “ 段落 “ 等根本元素。它由前端基础设施团队领有，并在其本人的解耦代码库中开发。所有这些组件都在 Bit.dev 上公布和共享。在那里，它们能够很容易地被任何其余须要它们的团队发现并集成到新我的项目中。而且，团队建设的 base-ui 能够一直增发更新到特定组件。

[

](https://bit.dev/bit/base-ui)

base-ui.Bit.dev 的根本组件设计零碎。Bit.dev 的根本组件设计零碎

第二个范畴叫做 ”** 营销 s://bit.dev/bit/evangelist)”。这是咱们具体的面向营销的组件零碎，用于在咱们的利用中构建营销页面。它由营销团队自主领有，并在[解耦代码库中开发。所有这些组件都在 Bit.dev 上公布和共享，并由营销团队保护。

[

](https://bit.dev/bit/evangelist)

布道者。Bit.dev 的营销组件零碎

在这个例子中，营销团队与构建 Bit.dev 网络平台的团队是脱钩的。这个团队在不同的代码库中工作，通过本人的解耦构建管道公布变动，并能一直提供增量降级。

每个团队都在本人的较小的、解耦的代码库中构建本人的组件，并灵便地按性能等划分垂直所有权。他们应用 Bit 来独立地对每个组件进行版本、构建、测试、打包和公布。他们应用 bit.dev 平台来托管并向其余团队公开组件，这样他们就能够进行整合和合作。

Bit 的每个团队都享有相似的工作流程。所有的团队都在一起工作，相互分享和集成组件，而不会踩到对方的脚趾。在咱们的代码库中编写的组件中，有靠近 100% 的组件是共享和重用的，不仅包含前端组件，还包含咱们零碎的许多其余方面，如 “ 搜寻 “ 性能、” 游乐场 “ 性能，甚至某些全栈性能，包含前端和后端性能。咱们发现这很有价值。

咱们为本人和其余团队采取的 KPI 和基准测试显示，在采纳这种组件驱动的设计时，产生了各种踊跃的事件。例如，公布的数量能够减少 30 倍(!)，花在集成上的工夫缩小了 50% 以上，新性能的组成变成了几小时或几天的事件，甚至新开发人员的入职也能够变成简略的几小时而不是几周的事件。你能够在【HeavyBit JAMStack 播客】(https://www.heavybit.com/libr…，亲耳听到更多对于这种变动，以及它对一个疾速成长的守业公司的作用。

那么，微前端到底是什么？

近年来，微服务容许后端架构通过涣散耦合的代码库进行扩大，每个代码库负责本人的业务逻辑，并暴露出一个 API，每个代码库都能够独立部署，并且每个代码库都由不同的团队领有和保护。

[

](https://martinfowler.com/arti…

Source: This wonderful article by Cam Jackson

这种模式提供了微小的劣势，有助于减速、扩大和进步开发过程的效率。

微前端的理念是将同样的劣势带到古代开发工作流程中。它意味着将单体我的项目分解成更小、更易治理的碎片，这些碎片由各自的团队独立开发和领有，并具备同时构建和出货的能力。

这个概念能够提供微小的劣势，比方简略的、解耦的代码库、自主的团队、独立的公布和增量的降级。大大放慢了开发过程，扩充了规模，进步了效率。

那为什么当初能够，以前就不行呢？

直到最近，大多数网络应用依然是作为繁多的单体我的项目来构建的。GatsbyJS 的创始人 Kyle Mathews 说得很好，他说：_” 明天的网站依然是用 20 年前的形式来制作的，用繁琐的单体办法来构建网站、存储数据和交付内容。是时候用一种新的形式来构建网络了 ”_。

然而明天，组件是古代网络的规范基元。只是当初，这些模块化和可重用的部件才达到了真正的能力，成为咱们网络应用的构件，实现了传统单体的模块化合成。当初，为了开掘这个机会，须要一个共享的基础架构，以促成团队独特构建 Web 利用的模块化组件驱动设计。

这就是像 Bit 这样的新工具的作用，提供必要的工具集，以便在架构和组织层面采纳和享受组件驱动开发，并实现这些潜在的益处。

Bit 能够让开发人员将独立组件的开发、重用和公布解耦，从而能够高效地开发、重用和集成这些组件以组成不同的应用程序。这使得 Bit 成为一个弱小的工具，不仅实用于设计零碎和共享组件，而且实用于构建微前端。

在 Bit，咱们从第一天开始就始终与微前端单干。这也是咱们设计和测试咱们本人的工具的形式，以便它们可能帮忙其余团队更好地构建组件。明天，咱们的工具帮忙超过 10 万名开发者享受到了相似的益处。

在这篇文章中，我将分享咱们本人的团队是如何用组件构建微前端的。我将展现并解释咱们是如何将 Web 开发宰割成解耦的、可保护的代码库，如何让新性能和新技术易于替换或集成，如何让团队自在地独立构建并向生产公布变更而不至于绊住对方的脚步，如何实现高达 100% 的组件复用，如何构建既可扩大的架构和组织构造，又能随着咱们的倒退而顺利成长。

Our shared component infrastructure

[

](https://bit.dev/)

当然，不同的团队应用不同的堆栈和工具来构建他们的技术。

对于咱们网络平台和网站的开发，咱们抉择了 React。随着 Hooks 和 Context-API 等性能的公布，React 成为了咱们从更小的、独立的、可重用的碎片开发古代利用的绝佳抉择。

对于反对组件驱动的微前端的 shard 基础设施，咱们应用了 Bit 的开源工具和云平台。

除了日常的狗粮化产品，Bit 还为咱们提供了一些采纳咱们微前端架构的必要性能。

1. 咱们的 OSS 工具](https://github.com/teambit/bi…，模块化的工作空间能够帮忙咱们用独立的组件进行构建。组件能够独立开发、渲染、构建、测试、版本、公布，甚至能够通过 CI，而不须要耦合到任何具体的我的项目中。

此外，Bit 还提供了两个要害个性。首先，它提供了对所有组件的依赖关系图的通用管制。它主动解析每个组件的依赖关系，只有任何依赖关系发生变化，它就会让你精确地晓得应该扭转什么。其次，它提供了 0 配置的可重用和可定制的开发环境，因而组件能够通过本人的构建管道与任何更大的我的项目拆散，这些变动能够在整个组件的依赖图中构建。

这听起来如同很多，事实也是如此，但 Bit 实际上让构建独立的组件变得非常简单，这些组件能够自行开发和公布。

2. 咱们的云平台为团队 (包含咱们本人) 提供了一个合作核心，在这里，每个人都能够公布组件，轻松地记录它们(比特将这一过程自动化)，发现和装置它们。这让咱们的团队能够共享和重用咱们构建的靠近 100% 的组件。

为了确保每个前端都能取得本人独立的疾速构建流程，Bit 还提供了独特的CI/CD 流程，它是 **100% 组件驱动的，这意味着不同的团队能够平安地集成变更，而无需期待、抢夺主控权或毁坏任何货色。开发人员能够在所有受影响的应用程序中继续、平安地流传对组件的变更。

与其在一个构建过程中构建所有团队都必须经验的单体我的项目，组件驱动的 CI 将构建过程宰割开来，使其只运行在理论发生变化的组件上，并将变动有限地流传到其依赖图上，以构建每一个受影响的组件，在每一个应用程序的每一个页面上。

这让咱们能够将不同团队的公布管道从彼此之间解放出来，这样每个团队就能够独立地、继续地公布变更和更新到生产中。这也意味着大概 50 倍的构建速度，因为并不是所有的货色都会被构建。而且，咱们能够将问题和谬误准确到具体的组件。

胜利的变更能够主动转化为拉取申请，并主动发送给所有相干我的项目，这样他们的维护者就能够平安地采纳这些变更，并确保他们的应用程序始终保持最新版本。Bit.dev 还为咱们提供了不同我的项目中所有组件的概览，这样咱们就能够精确地监控和标准谁在什么版本中应用哪个组件。

咱们的流程

康威法令](https://en.wikipedia.org/wiki…，软件架构和组织构造之间有很强的关联性。在构建微前端时，这是十分正确的，因为次要指标是让组织更有效率。解耦代码库，实现集成，或者宰割公布管道，都是构建更好的软件以及自主麻利团队的办法。

Autonomous teams

一个小团队被受权做决定，并不懈地朝着指标后退，会比一个大团队更快地提供后果和洞察力。毕竟，有谁比领有产品的团队更理解产品的用户和问题呢？

因为咱们的组件驱动架构的灵活性，咱们可能调配团队的所有权，并以一种更加动静、垂直和上下文相干的形式。咱们没有让 bit.dev 的 “ 前端团队 “ 和 “ 营销网站团队 “ 一起在一个单体利用上工作，而是在各个方面将这些团队齐全离开。

首先，有几个开发人员被认为是 “ 前端基础设施团队 ”，他们间接汇报保护 bit.dev 平台的一套根本组件。在这个团队中，还有一名设计师、一名产品经理和一些利益相关者。他们独立于其余应用这些性能的团队构建、公布和更新性能。

“ 组件搜寻 “ 团队，负责 bit.dev 上的简单搜寻性能，由几个开发人员（包含前台和后盾）、一个 NLP 研究员和一个产品经理组成。它将组件裸露进去，供其余团队集成到他们的产品中。

“ 组件发现 “ 团队包含几名开发人员、一名兼职设计师和一名兼职产品经理，以构建一套用于记录、可视化和交互的组件，这些组件在 bit.dev 平台上共享。事实上，因为比特的缘故，无论是在比特的本地开发工作区，还是在云平台上，同样的文档组件都是由这个团队构建的。

又有几个开发人员被调配到营销团队，与几个营销人员和一个设计师一起构建营销的一套组件，这些组件被用来组成咱们的营销网站，以及一些更多的利用。

客户胜利团队，有本人的开发人员，构建和保护本人的一套组件，这些组件实现了整个 Bit.dev 平台上应用的不同的用户交互，甚至在咱们构建的其余网站和利用中也应用。

这样的例子举不胜举，而每个性能都成为一个团队自主负责构建和运维的组件，供其余团队也整合和应用。

简略的、解耦的代码库

解耦代码库使性能更容易开发、测试、保护、替换或降级。咱们心愿可能一直减少新的技术和性能。

咱们的每个团队都在一个齐全不同的、解耦的代码库中工作。它开发、测试和保护本人的性能，而没有与其余团队在 comlex 单体中工作的限度和苦楚。

每个性能或产品的源代码天然要比整个利用的源代码小得多，也简略得多，这使得 eah 代码库更容易开发、测试和保护，而没有在一个单体外部独特工作的限度和苦楚。

如果你回顾一下 bit.dev 主页上的 “base-ui “ 和 “evangelist “ 例子，你会发现每一套组件都是在不同的代码库中开发的。这两套组件都是互相解耦的，并被集成在一起以创立不同的页面、性能和应用程序。

因为所有的代码库都是互相解耦的，而且每一个代码库都是由大部分甚至是齐全由组件组成的，因而，逐渐重构咱们的应用程序的局部也变得容易得多（很多），这样咱们就能够疾速而平安地增加或替换技术。

随着工夫的推移，必须明确定义哪些代码属于每个代码库，是一个很好的办法，能够更好地了解咱们正在构建的架构，以及每个局部在其中的作用。

独立的开释管道

咱们可能将不同团队的公布流水线互相拆分、解耦，让每个团队都能独立构建并公布多个利用的变更，而不须要期待版本臃肿或抢夺主分支。

如上所述，通过 Bit 和 Bit.dev，咱们可能为每个团队的组件集指定一个自定义但标准化的构建管道。因而，只管是独自构建，但所有组件都能够通过雷同的工作和工具。

而后，Bit.dev（Beta 版）上的（速度快 50 倍）组件驱动的 CI 流程会在每一个页面和每一个利用中映射和构建扭转所有依赖组件的流传依赖图。

用简略的话说，每个团队都能够对任何组件进行更改，独立构建这些更改，并理解它是否以及如何在所有相干利用中毁坏其余组件和其余团队。

如果一切顺利，这些变更会主动转化为 Pull-Request，发送到所有相干我的项目，这样它们的所有者就能够更新他们的组件。他们甚至能够通过 Slack 取得告诉和揭示。在 Bit.dev 的 “ 我的项目 “ 性能中（咱们团队的另一个我的项目），咱们能够查看和监控谁采纳了哪个 PR，在哪里。

因而，咱们不须要再去搞繁琐的 iframes，也不须要再去寻找其余的解决方案，而是依附构建时的集成，不将咱们的公布流程耦合在一起。目前，这对咱们来说成果十分好，咱们的组件驱动的 CI 将在几周内推出 Beta 版，所以当它进去时，也能够随时试驾。在将来，咱们的确有一个打算，要一路走上来，实现组件驱动的利用部署。

有限的组件复用和合作

[

](https://bit.dev/)

咱们将所有的组件公布到 Bit.dev. 上，在那里，咱们所有的团队都会以乏味和无效的形式互相分享、发现、合作和重用组件。在那里，咱们所有的团队都能以乏味而无效的形式互相分享、发现、合作和重用组件。

新增的性能，如可视化组件文档、智能组件搜寻，甚至是实时模仿，都有助于让咱们所有的组件都能被发现，这样咱们就不须要保护任何额定的文档网站、注册表或工具。

这种合作零碎使开发人员更容易分享代码、提出反馈意见，并确保一致性。咱们特地喜爱这样的事实：它能够帮忙新退出团队的开发人员缩短学习曲线，因为他们能够找到并开始应用现有的组件，这样他们就能够立刻开始构建。

对咱们来说，这也是改善开发人员和其余利益相关者之间单干的有用办法，比方咱们的设计师和产品，他们当初能够看到咱们所有的组件。

论断

有人说微前端无非是一种 “ 好的组件模式 ”。对于咱们来说，它是一个好的组件模式，同时也是一个更好的形式来建设咱们本人的团队，改善咱们的工作形式，构建更好的模块化软件，并更快、更频繁地交付。

对于大型组织来说，独立的团队交付是他们构建和公布胜利的 Web 应用程序的能力的真正游戏扭转者。标准化组件开发，并容许团队互相分享和合作的能力也是如此。

对于小团队来说，采纳灵便和可扩大的架构将进步他们的倒退能力，疾速增加新性能，招收新员工，专一于核心技术和翻新，而不是专一于不那么重要的事件。

心愿你能在组件驱动的微前端的理念中找到对你有用的货色，谢谢你的浏览!