共计 2748 个字符，预计需要花费 7 分钟才能阅读完成。
Florian Rappl 原作，受权 New Frontend 翻译。
微前端是前端开发最具争议的话题之一。值得吗？真的须要切分利用吗？真的需 当初 就转向微前端吗？这是不是又一个征询公司为了多赚钱创造进去的概念？
只管人们对微前端多有误会，咱们不能否定微前端日益风行这一事实。让咱们看下谁在应用微前端，到底为什么用微前端，还有一些 不便 上手的现成解决方案。
微前端到底是什么
微前端试图把拆分大型后端系统的一些好处引入前端。
最大的问题在于局部总是被整体应用。
后端系统从不被整体应用，而前端间接为用户体验（UX）负责。
应答这一问题有很多形式。最简略的形式是把现有的 API 数据交换模型换成 HTML 输入，只需一个超链接就能够从一个服务（视图）转到另一个服务（视图）。毛病是在大多数应用场景下，这么做必定无奈满足用户体验方面的需要。
显然，咱们须要更简单的办法，将独自开发的用户界面小组件组合成统一的前端界面。这能够算是分布式 web 利用演进的下一步。
微前端和组件、模块的关系是什么？这是一个好问题。这些概念都意味着通过拆分单元的形式让代码更易复用，更易归责。惟一的差异是档次不同：
- 组件形成界面库。
- 模块形成相应的运行时。
- 包形成依赖关系。
- 微前端形成出现的利用。
因而，如果把微前端比作器官，那么包就相当于细胞，模块就相当于分子，组件就相当于原子。
为什么要用微前端
采纳微前端的起因有许多种，常常次要是为了技术自身，不过，现实状况下，采纳微前端是基于实在业务场景，或是出于改善用户体验的须要。
微前端计划的外围在于谋求以下个性：
- 前端各局部能够 独自 开发、测试、部署。
- 前端各局部的减少、移除、替换 无需从新构建。
- 前端各局部能够采纳 不同 的技术。
因而，微前端的精华在于 解藕。利用达到特定规模后，微前端开始变得有意义。其中一个益处是更多潜在的团队划分可能性，包含组建更小的全栈团队。
在满足以下一项或多项条件时，微前端值得思考：
- 多个团队奉献前端代码
- 面向特定用户或用户组激活、敞开、推出前端的某一部分
- 容许内部开发者扩大用户界面
- 用户界面每天或每周都会退出新个性，同时又不能影响零碎的其余局部
- 在利用增长的状况下放弃开发速度恒定
- 不同团队可能应用本人的工具
谁在用微前端
有越来越多的公司正在应用微前端，包含：
- DAZN
- Elsevier
- entando
- Fiverr
- Hello Fresh
- IKEA
- Bit.dev
- Microsoft
- Open Table
- OpenMRS
- Otto
- SAP
- Sixt
- Skyscanner
- smapiot
- Spotify
- Starbucks
- Thalia
- Zalando
- ZEISS
- …… 以及更多
这些公司应用微前端的具体形式各不相同，不过，应用微前端的用意大同小异。
（上图来自 Luca Mezzalira）
这个列表每天都在增长，从 ThoughtWorks、HLC 这样的征询公司到 SalesPad、Apptio 这样的 SaaS 提供商。然而很多传统的公司也开始押注微前端。德国的隐形冠军霍夫曼团体就是其中的一个例子。
霍夫曼团体是一个很好的例子，微前端不须要十分大的团队，也不须要公司外部的资源。霍夫曼集团选择微前端的起因正是因为它们要和多个服务提供商打交道。
微前端组件的例子
[Bit.dev] 平台和营销网站都是基于 React 组件构建，治理 React 组件是通过……Bit。
看看它们的页面。悬停在不同组件上会显示这些组件本来属于哪个组件集。点击组件名能够查看组件，甚至在你的我的项目中退出这一组件。
这个页面是通过两个组件集中的组件构建的，这两个组件集对应 GitHub 上两个不同的代码仓库，[base-ui] (Bit.dev 页面) 和 evangelist。
base-ui 组件集起到了设计零碎的作用。evangelist 组件集中的组件（用于营销页面）应用了 base-ui 中的一些组件，以便在不同的微前端上放弃对立的格调。
在这个例子中，Bit 既用于实现自主交付，也用于放弃不同微前端的界面统一。
如何构建微前端
很可怜，这个乏味的问题只有一个含混的答案：就像微服务一样，并不存在实用于所有人的繁多办法，也没有业界规范。
不同于微服务，微前端引入了根本性的差别，而不仅仅是实现细节上的差别。所以，咱们须要辨别微前端的应用范畴。一些服务端框架也容许客户端复合（client-side composition），不过，相同的状况也是成立的。
客户端框架
客户端微前端框架有很多，有些也同时反对服务端渲染。
以下框架实现了微前端模式（或相似微前端的模式）：
- Piral
- Open Components
- qiankun
- Luigi
- Frint.js
服务端框架
服务端微前端框架也不少。有些不过是基于 express 的库或框架，但另一些框架则须要依靠于你的基础设施。
以下框架实现了微前端模式（或相似微前端的模式）：
- Mosaic
- PuzzleJs
- Podium
- Micromono
辅助库
还有一些辅助库提供了一些基础设施，例如共用依赖、路由事件、组合不同的微前端及其生命周期。
上面是一个 [解决共用依赖] 的例子，利用了 import maps、chunk（webpack 外部应用的一个概念）之类的机制。
上面这些库有助于缩小模板代码：
- Module Federation
- Siteless
- Single SPA
- Postal.js
- EventBus
微前端调研
我心愿当前基于 社区数据 从新梳理一下这部分的内容。但我须要你们帮忙提供数据。
我用 谷歌表单做了一份简略的调查表，应该能在 5 分钟之内填完。请帮忙扩散（比方通过 Twitter）。非常感谢！
考察到八月底截止，九月初会发表后果。
微前端的下一步
只管有些人感觉微前端会个体转向模块聚合（module federation）之类的辅助库，大多数人仍将应用自研解决方案。好消息是在许多框架下很容易编写避开强供应商锁定的代码。不管怎么说，微前端短少一个公共规范，不便在技术层面替换解决方案。
另外，目前微前端仍未被社区宽泛承受和采纳。
只管微前端模式变得风行，社区中仍有很多人心存疑虑。
有一个起因是微服务并没有被视为面向特定场景的另一个工具，而是被视为设计后端时的一种最佳实际和规范。显然微服务不应该这么用。因而，微前端也 不应该被视为银弹。
结语
微前端有许多现成的解决方案，许多我的项目也曾经采纳微前端，这是一个强烈的信号：微前端已就绪！我倡议在开始一个具备肯定规模的生产环境我的项目前，先调研下各种模式和计划。
我心愿你喜爱这篇文章！我心愿晓得你持哪一方的观点及其起因。你喜爱微前端，能够容忍微前端，还是厌恶微前端？
Photo by Ben Allan on Unsplash
参考
- Building a UI Component Design System
- 6 Patterns for Microfrontends
- How to Publish React Components
