上一篇微前端到底是什么已经从概念定义及实现思路上探究了微前端是什么的问题,而要彻底理解微前端的话,还需要想清楚这些问题:
从最初的 HTML 内联脚本,到 9102 年的几十万行 JavaScript 代码,前端已经变得越来越重:
也越来越复杂:
因而需要一种分解复杂度、提升协作效率、支持灵活扩展的架构模式,于是,微前端登上了舞台
微前端的理念类似于微服务,将庞大的整体拆成可控的小块,并明确它们之间的依赖关系。
通过拆分自治、支持多技术栈并存的方式,解决前端应用所面临的种种问题:
按业务功能将一整块前端应用分解成一系列更小、更内聚的微前端应用,同时通过明确的交互协议来管理这些应用间的依赖关系,实现不同业务模块的解耦。并将每个微前端应用交由独立团队负责,各自独立开发独立部署,充分利用并行性
另一方面,在多技术栈并存能力的加持下,不仅能够低成本引入新的技术实践,还允许低风险地替换产品局部功能,意味着依赖项升级、架构更替、UI 改版等重大决策都能以循序渐进的方式平稳落地:
通过微前端框架建立应用间的主从关系(1 个容器应用 + n 个子应用),接着进行局部替换,直至全部完成。然而,实践中通常需要在重构的同时保证新特性的持续迭代,所以实际流程可能是:
让重构等工作能够在相对较长的时间跨度下可控地渐进完成,而无需承担一刀切的资源需求与变更风险
The problems they’re supposed to solve sound to me like they’re already solved by a good component model. So is this solving an organizational issue rather than technical one? Such as if two teams can’t agree on anything, even shared infra.
(摘自I don’t understand micro-frontends.)
诚然,组件化也能实现拆分自治,比如在 React 中可以通过React.lazy + Suspense的方式优雅地完成代码拆分
但这建立在组件模型统一(或者说技术栈一致)的前提下,而微前端的另一半优势在于能够打破单一技术栈的限制:
They are microservices in the browser. Meaning separately built and deployed frontend apps that can choose their own framework and libs. The purpose is organizational scaling and avoiding framework lock-in.
这是组件化、模块化等方案所无法满足的。同样的,git submodule、npm module 等拆分方案也都无法直接提供多技术栈并存的能力
一半来自模块化带来的好处,诸如:
另一半来自多技术栈并存能力的好处:
当然,允许多技术栈并存,并不意味着鼓励引入尽可能多的技术栈,因为更少的技术栈通常更有利于基础设施建设、资源复用与经验共享
微前端视角下的 Web 应用是一系列独立功能的组合:
The idea behind Micro Frontends is to think about a website or web app as a composition of features which are owned by independent teams.
(摘自What are Micro Frontends?)
因此,微前端应用能够像云计算背景下的云服务一样能够即取即用,实现应用模块级(第三方)功能的接入/融合,其商业价值在于: