微前端的现状和趋势
Florian Rappl 原做，受权 New Frontend 翻译。前端
微前端是前端开发最具争议的话题之一。值得吗？真的须要切分应用吗？真的需如今就转向微前端吗？这是否是又一个咨询公司为了多赚钱发明出来的概念？react
尽管人们对微前端多有误解，咱们不可否认微前端日益流行这一事实。让咱们看下谁在使用微前端，到底为何用微前端，还有一些方便上手的现成解决方案。webpack
微前端究竟是什么
微前端试图把拆分大型后端系统的一些益处引入前端。git
最大的问题在于部分老是被总体使用。
后端系统从不被总体使用，而前端直接为用户体验（UX）负责。github
应对这一问题有不少方式。最简单的方式是把现有的 API 数据交换模型换成 HTML 输出，只需一个超连接就能够从一个服务（视图）转到另外一个服务（视图）。缺点是在大多数使用场景下，这么作确定没法知足用户体验方面的需求。web
显然，咱们须要更复杂的方法，将单独开发的用户界面小组件组合成一致的前端界面。这能够算是分布式 web 应用演进的下一步。express
微前端和组件、模块的关系是什么？这是一个好问题。这些概念都意味着经过拆分单元的方式让代码更易复用，更易归责。惟一的差异是层次不一样：npm
- 组件构成界面库。
- 模块构成相应的运行时。
- 包构成依赖关系。
- 微前端构成呈现的应用。
所以，若是把微前端比做器官，那么包就至关于细胞，模块就至关于分子，组件就至关于原子。后端
为何要用微前端
采用微前端的缘由有许多种，常常主要是为了技术自己，不过，理想状况下，采用微前端是基于真实业务场景，或是出于改善用户体验的须要。api
微前端方案的核心在于追求如下特性：
- 前端各部分能够单独开发、测试、部署。
- 前端各部分的增长、移除、替换无需从新构建。
- 前端各部分能够采用不一样的技术。
所以，微前端的精髓在于解藕。应用达到特定规模后，微前端开始变得有意义。其中一个好处是更多潜在的团队划分可能性，包括组建更小的全栈团队。
在知足如下一项或多项条件时，微前端值得考虑：
- 多个团队贡献前端代码
- 面向特定用户或用户组激活、关闭、推出前端的某一部分
- 容许外部开发者扩展用户界面
- 用户界面天天或每周都会加入新特性，同时又不能影响系统的其余部分
- 在应用增加的状况下保持开发速度恒定
- 不一样团队可以使用本身的工具
谁在用微前端
有愈来愈多的公司正在使用微前端，包括：
- 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），不过，相反的状况也是成立的。
客户端框架
客户端微前端框架有不少，有些也同时支持服务端渲染。
如下框架实现了微前端模式（或相似微前端的模式）：
服务端框架
服务端微前端框架也很多。有些不过是基于 express 的库或框架，但另外一些框架则须要依托于你的基础设施。
如下框架实现了微前端模式（或相似微前端的模式）：
辅助库
还有一些辅助库提供了一些基础设施，例如共用依赖、路由事件、组合不一样的微前端及其生命周期。
下面是一个[处理共用依赖]的例子，利用了 import maps、chunk （webpack 内部使用的一个概念） 之类的机制。
下面这些库有助于减小模板代码：
微前端调研
我但愿之后基于社区数据从新梳理一下这部分的内容。但我须要大家帮忙提供数据。
我用 谷歌表单作了一份简单的调查表，应该能在 5 分钟以内填完。请帮忙扩散（好比经过 Twitter）。很是感谢！
调查到八月底截止，九月初会发表结果。
微前端的下一步
尽管有些人以为微前端会集体转向模块聚合（module federation）之类的辅助库，大多数人仍将使用自研解决方案。好消息是在许多框架下很容易编写避开强供应商锁定的代码。无论怎么说，微前端缺乏一个公共标准，方便在技术层面交换解决方案。
另外，目前微前端仍未被社区普遍接受和采用。
尽管微前端模式变得流行，社区中仍有不少人心存疑虑。
有一个缘由是微服务并无被视为面向特定场景的另外一个工具，而是被视为设计后端时的一种最佳实践和标准。显然微服务不该该这么用。所以，微前端也不应该被视为银弹。
结语
微前端有许多现成的解决方案，许多项目也已经采用微前端，这是一个强烈的信号：微前端已就绪！我建议在开始一个具备必定规模的生产环境项目前，先调研下各类模式和方案。
我但愿你喜欢这篇文章！我但愿知道你持哪一方的观点及其缘由。你喜欢微前端，能够容忍微前端，仍是讨厌微前端？
Photo by Ben Allan on Unsplash