前端微服务架构(前端微服务架构的优缺点)
本篇文章给大家谈谈前端微服务架构,以及前端微服务架构的优缺点对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。
本文目录一览:
qiankun微前端框架处理
概念:微前端的概念借鉴于后端的微服务,一般以业务功能为拆分单元
解决问题:大型项目的变更、扩展、维护困难的问题
总体积变大,插件可上传cdn,但公共函数资源不便于共享
iframe :隔离性和兼容性好,性能和使用感差(性能差因为不会有缓存,每次重新加载)
基座模式 :基于 路由分发 ,由基座监听路由变化,加载不同的应用,实现应用解耦,single-spa、qiankun
组合式集成 :组件单独打包发布,类似于npm包
EMP :主要基于Webpack5 Module Federation
web components :
我们采用的是qiankun,主要思路是将一个大应用,拆分为更小的、可独立开发、测试、部署的子应用缺卖。
传统的大型项目:所有模块都在一个应用里,由应用本身负责路由管理,属于 应用分发路由 方式
拆分微应用的项目:属于基座模式下的系统架构,各应用互相独立,单独运行在信扮升不同的服务上,基座(基座一般是用户最终访滑老问的应用)根据路由去加载不同的应用到页面上,即 路由分发应用 方式
微前段主要需要解决的问题有两个
qiankun和single-spa对比
activePath与当前的hash对比一致
[img]微服务架构下,进行前后端分离,前端怎么写
分离后的前端,不再是一个简单的HTML文件,已经是一个独立的应用系统。除了要考虑页面的数据渲染展示,还要用工程化的思想来考虑前端的架构,前后端的交互和数据安全等事情。
RESTful接口交互
前后端分离之后,更多的是采用RESTful风格的接口与后端进行数据交互。
REST是“呈现状态转移(REpresentational State Transfer)”的缩写,一种API的架构风格,在客户端和服务端之间通过呈现状态的转移来驱动应用状态的演进。
在 REST 样式的 Web 服务中,每个资源都有一个地址。资源本身都是方法调用的目标,方法列表对所有资源都是一样的。这些方法都是标准方法,包括 HTTP GET、POST、PUT、DELETE,还可能包括 HEADER 和 OPTIONS。
RESTful的API设计,使得后端通过接口向前端传递数据,数据的格式通常是JSON这种通用的则败芹格式。对前端来说,只要后端返回过来的是RESTful的数据就行孙毕,不管后端是用Java写,还是用python或PHP,拜托对后端的依赖,做到前端系统的独立。
工程化构建
Nodejs不止可以用来做前端服务器,在开发阶段,它也能发挥很大的作用。
前端生态的发展,是围绕着Nodejs进行的。用npm来管理项目依赖,可以很好的维护和运行在Nodejs环境上。
打包工具grunt、gulp、webpack和rollup等,都是运行在nodejs上,再结合语法编译、打包部署等插件,将应用输入成一个完整的应用。
如果你使用了Angular、React或Vue框架,或者你使用浏览器暂时还不兼容的ES6语法,还需要在应用打包前用babel将语法编译成浏览器可识别的ES5的语法。
SPA
SPA是单页Web应用(single page web application,SPA)的简写,就是只有一张Web页面的应用,是加载单个HTML 页面并在用户与应用程序交互时动态更新该页面的Web应用程序。
像Angular、React或Vue就是为了SPA而设计的,结合前端路由库(react-router、vue-router)和状态热存储(redux、vuex)等,可以开发出一个媲美Native APP的Web APP,用户体验得到了很大的提升。
当然,SPA也不是完美的,也不是适合所有的web应用,需要结合项目和场景来选择。
SPA有如下缺点:枯明
初次加载耗时增加。可以通过代码拆分、懒加载来提升性能,减少初次加载耗时。
SEO不友好,现在可以通过Prerender或Server render来解决一部分。
页面的前进和后端需要开发者自己写,不过现在一些路由库已经帮助我们基本解决了。
对开发者要求高,由于做SPA需要了解一整套技术栈,所以,要考虑后期是否有合适的人选进行维护。
微服务架构~BFF和网关是如何演化而来
BFF(Backend for Frontend)和网关Gateway是微服务架构中的两个重要概念,这两个概念相对比较新,有些开发人员甚至是架构师都不甚理解。(伟哥一直是做前端的,第一次听师父说BFF这个问题,还以为他说错了,前端没有BFF,BFC倒是有一个