前端微服务架构(前端微服务架构的优缺点)

本篇文章给大家谈谈前端微服务架构,以及前端微服务架构的优缺点对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。

本文目录一览:

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倒是有一个

标签列表