翻译自 https://micro-frontends.org/
本文描述了采用不同 JavaScript 技术框架的多个团队中协同构建一个现代化前端 Web 应用所需要的技术、策略和方法。
什么是微前端？微前端这个术语最初来自 2016 年的 ThoughtWorks 技术雷达[ https://www.thoughtworks.com/radar/techniques/micro-frontends ]，它将微服务的概念扩展到了前端领域。目前的趋势是构建一个功能丰富且强大的前端应用，即单页面应用(SPA)，其本身一般都是建立在一个微服务架构之上。前端层通常由一个单独的团队开发，随着时间的推移，会变得越来越庞大而难以维护。这就是传说中的前端巨无霸(Frontend Monolith) [ https://www.youtube.com/watch?v=pU1gXA0rfwc ]。
微前端背后的理念是将一个网站或者 Web App 当成特性的组合体，每个特性都由一个独立的团队负责。每个团队都有擅长的特定业务领域或是它关心的任务。这里，一个团队是跨职能的，它可以端到端，从数据库到用户界面完整的开发它所负责的功能。
然而，这个概念并不新鲜，过去它叫针对垂直系统的前端一体化或独立系统。不过微前端显然是一个更加友好并且不那么笨重的术语。
一体化的前端
垂直化组织方式
在介绍中我使用了措辞“构建一个现代化前端应用”，让我们先给出一些这个术语有关的设定。
从一个更广泛的角度来看，Aral Balkan 曾写过一个相关的博客，他把这个概念叫做文档-应用连续统一体。他提出了一个滑动比例尺的概念，在比例尺的最左边是一个网站，由静态文档构成，通过链接相互连接；最右边是一个纯行为驱动的，几乎没内容的应用程序，比如在线图片编辑器。
如果你把你的项目定位在这个范围的左侧，那在 Web 服务器级别的集成会比较合适。在这个模型中，服务器会收集页面中各个组件的内容并将其 HTML 字符串连接起来返回给用户。内容更新则采用从服务端重新加载的方式或者通过 ajax 进行部分替换。Gustaf Nilsson Kotte 针对这个主题写过一篇综合性的文章。
当用户界面需要提供及时反馈时，即使采用不可靠连接，一个纯粹的服务端渲染网站也不够用。为了实现 Optimistic UI 或 Skeleton Screens 这样的技术你需要在设备本身对 UI 进行更新。Google 提出的 PWA 巧妙的描述了这种兼顾各方的做法（渐进增强），同时提供 App 一样的性能体验。这种类型的应用在上面的比例尺中位于文档-应用连续统一体中间的某个地方。在这里纯粹的服务端方案已经不再够用，我们必须将主要逻辑放到浏览器中，这正是本文会重点描述的。
微前端背后的核心理念技术无关
每一个团队在选择和升级他们的技术栈时应该能够做到不需要和其他团队进行对接。Custom Elements 是一个隐藏实现细节的非常好的方法，同时能够对外提供一个统一接口。
隔离团队代码
即使所有的团队都使用同样的框架，也不要共享一个运行时。构建独立的应用，不要依赖于共享状态或全局变量。
建立各团队的前缀
当隔离已经不可能时要商定一个命名规范。对 CSS、Events、Local Storage 和 Cookie 建立命名空间来避免碰撞并声明所有权。
本地浏览器特性优先于自定义 API
采用浏览器事件进行数据沟通而不是构建一个全局的发布者-订阅者系统。如果你确实需要构建一个跨团队的 API，那就确保它越简单越好。
构建自适应网站
即使 JavaScript 执行失败或是根本没有执行，你的特性也应该是能够使用的。采用通用渲染或渐进式增强来提高可感知的性能。
DOM 就是 API自定义元素 Custom Elements 面向 Web 组件规范中互操作方面，在浏览器中是一个适用于功能集成的基本元素。每个团队采用自己选择的 Web 技术构建他们的组件，并将它们封装到一个 自定义元素 中(比如 <order-minicart></order-minicart> )。这个特定元素的 DOM 声明(标签名、属性和事件)对于其他团队来说体现为一个协定或者叫公共 API。这样做的好处是其他人可以使用这个组件及其功能而不需要知道实现细节，他们只需要能够和 DOM 交互即可。
但仅仅自定义元素是不能满足解决方案的所有需求的。为了处理渐进增强、通用渲染或路由我们还需要软件的其他部分。