微前端(Micro-Frontends)是一种类似于微服务的架构,它将微服务的理念应用于浏览器端,即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。微前端(micro-frontends)术语在 2016 年在 TECHNOLOGY RADAR 中被提及。
微前端架构具备以下的特点:
微前端架构旨在解决单体应用在一个相对长的时间跨度下,由于参与的人员、团队的增多、变迁,从一个普通应用演变成一个巨石应用(Frontend Monolith)后,随之而来的应用不可维护的问题。比如:
通过微前端拆分成一个容器应用和多个子应用之后,各个应用能够独立部署,相互之间隔离,从而做到:
通过Nginx配置反向代理来实现不同路径映射到不同应用,例如www.abc.com/app1对应app1,www.abc.com/app2对应app2,这种方案本身并不属于前端层面的改造,更多的是运维的配置。
优点:
缺点:
父应用单独是一个页面,每个子应用嵌套一个iframe,父子通信可采用postMessage或者contentWindow方式。
优点:
缺点:
每个子应用需要采用纯Web Components技术编写组件,是一套全新的开发模式
优点:
缺点:
使用 Module Federation,我们可以在一个应用中动态加载并执行另一个应用的代码,且与技术栈无关,并且能够共享模块,从而减小编译时间以及降低包体积。
优点:
缺点:
每个子应用独立构建和部署,运行时由父应用来进行路由管理,应用加载,启动,卸载,以及通信机制。
优点:
缺点:
组合式应用路由分发是目前业内普遍使用的一种方案,并且能够满足大部分需求,接下来我们详细来看看这种实现方式。
该方案使用的是基座模式,通过一个主应用(基座应用-Main APP),来管理其它应用(子应用-MicroAPP)。基座应用大多数是一个前端 SPA 项目,主要负责应用注册,路由映射,消息下发等,而微应用是独立前端项目,这些项目不限于采用 react,vue,angular 或者 jquery 开发,每个微应用注册到基座应用中,由基座进行管理,但是如果脱离基座也是可以单独访问。
当整个微前端框架运行之后,给用户的体验就是类似下图所示:
简单描述下就是基座应用中有一些菜单项,点击每个菜单项可以展示对应的微应用,这些应用的切换是纯前端无感知的
上面的实现过程主要如下:
注意:子应用也可以将包打成多个,然后利用 webpack 的 webpack-manifest-plugin 插件打包出 manifest.json
文件,生成一份资源清单,然后主应用的 loadApp 远程读取每个子应用的清单文件,依次加载文件里面的资源;不过该方案也没办法享受子应用的按需加载能力。
当主应用和微应用同屏渲染时,就可能会有一些样式会相互污染,可以采取以下两种方案:
而对于微应用与微应用之间的CSS隔离就非常简单,在每次应用加载时,将该应用所有的link和style 内容进行标记。在应用卸载后,同步卸载页面上对应的link和style即可。
每当微应用的 JavaScript 被加载并运行时,它的核心实际上是对全局对象 Window 的修改以及一些全局事件的改变,例如 jQuery 这个 js 运行后,会在 Window 上挂载一个 window.$ 对象,对于其他库 React,Vue 也不例外。为此,需要在加载和卸载每个微应用的同时,尽可能消除这种冲突和影响,最普遍的做法是采用沙箱机制(SandBox)。
沙箱机制的核心是让局部的 JavaScript 运行时,对外部对象的访问和修改处在可控的范围内,即无论内部怎么运行,都不会影响外部的对象。通常在 Node.js 端可以采用 vm 模块,而对于浏览器,则需要结合 with 关键字和 window.Proxy 对象来实现浏览器端的沙箱。
微前端通常不会限制应用采用的框架,如何在不同的应用,框架之间进行通信是一个需要仔细考量的决定。应用间通信有很多种方式,当然,要让多个分离的微应用之间要做到通信,本质上仍离不开中间媒介或者说全局对象。
通过事件进行通信应该是最简单、通用的方案了。
// 监听事件
window.addEventListener('message', (event) => {
// 处理事件
});
// 触发事件
window.dispatchEvent(new CustomEvent('message', { detail: input.value }))
消息订阅(pub/sub)模式的通信机制是非常适用的,在基座应用中会定义事件中心Event,每个微应用分别来注册事件,当被触发事件时再有事件中心统一分发,这就构成了基本的通信机制。
import { Observable } from 'windowed-observable';
const observable = new Observable('konoha');
observable.subscribe((ninja) => {
console.log(ninja)
})
observable.publish('Uchiha Shisui');
通过 Web Workers 进行事件通信。
import Worky from 'worky'
const worker = new Worky("some-worker.js");
worker.on("eventName", function (some, data) {
// 处理
});
worker.emit("someEvent", and, some, data);
主应用创建 state store,共享给子应用使用,适用于主、子应用技术栈相同的场景。
微前端是一种将单个巨型应用转变为多个微型应用聚合为一的应用,能够解决“巨石应用”的维护性问题。实现微前端的方式有很多种,每种方案都需要考虑应用隔离和应用通信的问题,目前较为普遍使用的是组合式路由分发的方式。
来源: 前端杂货铺
微前端架构是一种类似于微服务的架构,它将微服务的理念应用于浏览器端,即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。由此带来的变化是,这些前端应用可以独立运行、独立开发、独立部署。
在 Web 开发导论/微前端与大前端一文中,笔者简述了微服务与微前端的设计理念以及微前端的潜在可行方案。微服务与微前端,都是希望将某个单一的单体应用,转化为多个可以独立运行、独立开发、独立部署、独立维护的服务或者应用的聚合
“微前端架构”是一种使用微服务模式构建前端应用的方法。微前端的理念是将你的前端拆分为一组可独立部署、松散耦合的应用。然后将这些应用组装在一起以创建面向用户的单个应用程序
在过去的几星期里,随着 Martin Fowler 博客上,那篇 Cam Jackson 写的微前端的文章发布,到处都在讨论 Microfrontend。作为一个微前端 “专家”,我也分享一下:如何去落地微前端
微前端架构是一种设计方法,其中,前端应用被分解为多个松散而协同工作的半独立“微应用”。微前端的思想来源于微服务,其名称也遵循了微服务的命名方式。那么,微前端的优势和好处在哪?让我们一起通过这篇微前端教程来了解
就目前来看,微前端已经不是一个新话题了。随着越来越多的公司的深入研究,当前也提出了很多的解决方案。不过本文不是想要来介绍微前端,更想介绍项目如何一步步到达微前端架构的实际需求
核心的就是渲染器,它提供了最基础渲染能力,有了它,你可以实现微前端、微服务、远程组件、首屏渲染,甚至可以和 React、EJS 等配合使用。
微前端开发常见问题汇总,前端应用可以独立运行、独立开发、独立部署。微前端不是单纯的前端框架或者工具而是一套架构体系。其在开发中会有各种问题,今天小编整理了一下分享给大家!
Single SPA 是一个用于前端微服务的 javascript 框架。它使你可以在单页应用中使用多个框架,这样就可以按功能拆分代码,并 能使 Angular、React、Vue.js 程序一起运行
不同于单纯的前端框架/工具,微前端是一套架构体系,这个概念最早在2016年底由 ThoughtWorks 提出。 微前端是一种类似于微服务的架构,它将微服务的理念应用于浏览器端,将 Web 应用从整个的「单体应用」转变为多个小型前端应用的「聚合体」。
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!