前后端分离

Web实现前后端分离,前后端解耦

為{幸葍}努か 提交于 2019-11-28 19:44:03
一、前言 ”前后端分离“已经成为互联网项目开发的业界标杆,通过Tomcat+Ngnix(也可以中间有个Node.js),有效地进行解耦。并且前后端分离会为以后的大型分布式架构、弹性计算架构、微服务架构、多端化服务(多种客户端,例如:浏览器,车载终端,安卓,IOS等等)打下坚实的基础。 前后端分离(解耦)的核心思想是:前端Html页面通过Ajax调用后端的RestFul API并使用Json数据进行交互。 注:【在互联网架构中,web服务器:一般指像nginx,apache这类的服务器,他们一般只能解析静态资源。应用服务器:一般指像tomcat,jetty,resin这类的服务器可以解析动态资源也可以解析静态资源,但解析静态资源的能力没有web服务器好。】 一般只有Web服务器才能被外网访问,应用服务器只能内网访问。 二、为什么前后端分离 一般公司后端开发人员直接兼顾前端的工作,一边实现API接口,一边开发页面,两者互相切换着做,而且根据不同的url动态拼接页面,这也导致后台的开发压力大大增加。前后端工作分配不均。不仅仅开发效率慢,而且代码难以维护。 而前后端分离的话,则可以很好的解决前后端分工不均的问题,将更多的交互逻辑分配给前端来处理,而后端则可以专注于其本职工作,比如提供API接口,进行权限控制以及进行运算工作。而前端开发人员则可以利用nodejs来搭建自己的本地服务器

【转】前后端分离架构:Web实现前后端分离,前后端解耦

两盒软妹~` 提交于 2019-11-28 19:43:47
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。 本文链接:https://blog.csdn.net/weixin_37539378/article/details/79956760 一、前言 ”前后端分离“已经成为互联网项目开发的业界标杆,通过Tomcat+Ngnix(也可以中间有个Node.js),有效地进行解耦。并且前后端分离会为以后的大型分布式架构、弹性计算架构、微服务架构、多端化服务(多种客户端,例如:浏览器,车载终端,安卓,IOS等等)打下坚实的基础。 前后端分离(解耦)的核心思想是:前端Html页面通过Ajax调用后端的RestFul API并使用Json数据进行交互。 注: 【在互联网架构中,web服务器:一般指像nginx,apache这类的服务器,他们一般只能解析静态资源。 应用服务器:一般指像tomcat,jetty,resin这类的服务器可以解析动态资源也可以解析静态资源,但解析静态资源的能力没有web服务器好。】 一般只有Web服务器才能被外网访问,应用服务器只能内网访问。 二、为什么前后端分离 一般公司后端开发人员直接兼顾前端的工作,一边实现API接口,一边开发页面,两者互相切换着做,而且根据不同的url动态拼接页面,这也导致后台的开发压力大大增加。前后端工作分配不均。不仅仅开发效率慢

Shrio使用Jwt达到前后端分离

核能气质少年 提交于 2019-11-28 10:44:55
概述 前后端分离之后,因为HTTP本身是无状态的,Session就没法用了。项目采用jwt的方案后,请求的主要流程如下:用户登录成功之后,服务端会创建一个jwt的token(jwt的这个token中记录了当前的操作账号),并将这个token返回给前端,前端每次请求服务端的数据时,都会将令牌放入Header或者Parameter中,服务端接收到请求后,会先被拦截器拦截,token检验的拦截器会获取请求中的token,然后会检验token的有效性,拦截器都检验成功后,请求会成功到达实际的业务流程中,执行业务逻辑返回给前端数据。在这个过程中,主要涉及到Shiro的拦截器链,Jwt的token管理,多Realm配置等。 Shiro的Filter链 Shiro的认证和授权都离不开Filter,因此需要对Shiro的Filter的运行流程很清楚,才能自定义Filter来满足企业的实际需要。另外Shiro的Filter虽然原理都和Servlet的Filter相似,甚至都最终继承相同的接口,但是实际还是有些差别。Shiro中的Filter主要是在ShiroFilter内,对指定匹配的URL进行拦截处理,它有自己的Filter链;而Servlet的Filter和ShiroFilter是同一个级别的,即先走Shiro自己的Filter体系

微信第三方登录前后端分离实现思路

久未见 提交于 2019-11-28 07:17:10
微信第三方登录前后端分离实现思路 前端实现 这里说一下前后端的思路,页面加载时声明一个变量 state =‘时间戳+6位随机数’, 前端路径生成二维码, 其中有个 state 参数需要我们传递,这个参数你传什么,微信回调的时候就会给你返回什么。 我们用之前生成那个state,当用户点击微信登录的按钮,我们就通过以state值为key和后端进行websocket连接,同时弹出二维码页面。 state对前端来说就相当于一个令牌,告诉后端是谁在使用微信登录。目的在于,当后台收到回调的时候,能准确的把数据返回当前扫码的用户, 后台在微信回调的时候能拿到 code 的值和 state 的值,通过 code 去拿 access_token 和 openid , 通过这两个值去请求微信用户最新信息, 后端定义好返回的状态值代表啥,无非两种状态码:1.已经绑定:取出 user 信息, 通过websocket返回给前端,2.没绑定:返回微信账户的openid和头像昵称。 前端收到后端发送的websocket信息,判断微信绑定状态,如果绑定路由跳转到登录完成页面,如果未绑定,跳转到绑定或注册页面。 (想自学习编程的小伙伴请搜索 圈T社区 ,更多行业相关资讯更有行业相关免费视频教程。完全免费哦!) 第一步 前端先设置好生成二维码的路径, this.url = "https://open.weixin

前后端分离

馋奶兔 提交于 2019-11-28 06:13:51
前言 前后端分离已成为互联网项目开发的业界标准使用方式,通过nginx+tomcat的方式(也可以中间加一个nodejs)有效的进行解耦, 并且前后端分离会为以后的大型分布式架构、弹性计算架构、微服务架构、多端化服务(多种客户端,例如:浏览器,车载终端,安卓,IOS等等)打下坚实的基础。 这个步骤是系统架构从猿进化成人的必经之路。核心思想是前端html页面通过ajax调用后端的restuful api接口并使用json数据进行交互。 名词解释: 在互联网架构中, web服务器:一般指像nginx,apache这类的服务器,他们一般只能解析静态资源。 应用服务器:一般指像tomcat,jetty,resin这类的服务器可以解析动态资源也可以解析静态资源,但解析静态资源的能力没有web服务器好。 一般都是只有web服务器才能被外网访问,应用服务器只能内网访问。 术业有专攻(开发人员分离) 以前的JavaWeb项目大多数都是java程序员又当爹又当妈,又搞前端(ajax/jquery/js/html/css等等),又搞后端(java/mysql/oracle等等)。 随着时代的发展,渐渐的许多大中小公司开始把前后端的界限分的越来越明确,前端工程师只管前端的事情,后端工程师只管后端的事情。正所谓术业有专攻,一个人如果什么都会,那么他毕竟什么都不精。 大中型公司需要专业人才,小公司需要全才

为什么要用前后端分离?有什么优缺点

≯℡__Kan透↙ 提交于 2019-11-28 05:03:29
作 者:Cherry300 链接:jianshu.com/p/c86cee16b418 一、前戏 前后端分离已成为互联网项目开发的业界标准使用方式,通过nginx+tomcat的方式(也可以中间加一个nodejs)有效的进行解耦,并且前后端分离会为以后的大型分布式架构、弹性计算架构、微服务架构、多端化服务(多种客户端,例如:浏览器,车载终端,安卓,IOS等等)打下坚实的基础。这个步骤是系统架构从猿进化成人的必经之路。 核心思想是前端html页面通过ajax调用后端的restuful api接口并使用json数据进行交互。 在互联网架构中,名词解释: Web服务器:一般指像nginx,apache这类的服务器,他们一般只能解析静态资源。 应用服务器:一般指像tomcat,jetty,resin这类的服务器可以解析动态资源也可以解析静态资源,但解析静态资源的能力没有web服务器好。 一般都是只有web服务器才能被外网访问,应用服务器只能内网访问。 二、术业有专攻(开发人员分离) 以前的JavaWeb项目大多数都是java程序员又当爹又当妈,又搞前端,又搞后端。 随着时代的发展,渐渐的许多大中小公司开始把前后端的界限分的越来越明确,前端工程师只管前端的事情,后端工程师只管后端的事情。正所谓术业有专攻,一个人如果什么都会,那么他毕竟什么都不精。 大中型公司需要专业人才,小公司需要全才

gin+vue的前后端分离开源项目

北战南征 提交于 2019-11-28 02:44:33
该项目是gin+vue的前后端分离项目,使用gorm访问MySQL,其中vue前端是使用 vue-element-admin 框架简单实现的; go后台使用jwt,对API接口进行权限控制。此外,Web页面在token过期后的半个小时内,用户再次操作会自动刷新token; 项目很小,适合gin新手学习!(后续有时间会补上相关教程) GitHub地址: https://github.com/Bingjian-Zhu/gin-vue 一、运行go后台项目 (1)把项目clone到GOPATH/src目录下 (2)在MySQL中新建blog数据库,运行文件夹/docs/sql中的mysql.sql脚本 (3)在文件夹/conf中修改配置文件api.ini中的数据库连接配置 (4)在gin-vue目录下运行: go run main.go 目前为止,gin后台项目成功跑起来了 (5)可能遇到的问题 如果在GitHub是用下载压缩包的形式,解压后请把文件夹gin-vue-master重名为gin-vue,然后再复制到/GOPATH/src目录下 二、使用Postman测试API接口 (1)登录,token过期时间设为5分钟 (2)使用token调用API接口 (3)API权限验证 当使用admin登录获取的token调用/api/v1/table/list接口时,能获取到数据

前后端完全分离的思考

依然范特西╮ 提交于 2019-11-28 01:19:59
网站开发历程 1、杂合模式 早期的asp开发网站时期大多是如此, 一个asp文件混合业务处理,页面显示,js动态交互;完全杂合在一起; 一个请求对应一个asp文件,业务逻辑解析,动态输出html内容。 后期的php、早期的jsp也是如此模式; 2、webform模式 这个是微软asp.net时期的一个方式,本质上是封装html为服务器控件,动态生成html及相关提交和状态保持; 前后端分离,事件触发模式; 出发点是好的,但是这个模式问题太多。 简单的问题复杂化,导致大家学习成本增加,要单独取学习下服务器控件,这个完全背离了html简单简洁的原则。 导致各种代码冗余,开发代码的灵活性也降低到不行。 随着后来无刷新ajax技术流行,微软渐渐也是放弃了这个提交submit的交互模式,尽管后来有scriptmanager等也是各种难受, 封装到最后还不如直接用html来的科学,方便。 学习成本也是标高,和底层了解html背道而驰。 慢慢的就淡出了大家的视野。 3、模板引擎模式 一套独立的模板语法,这个好多的都是独立的模板引擎(包括现在微软的razor其实也才如此,只能说mvc也是low) 大多是基于自己开发的或者统一的模板引擎,将页面显示部分独立出来到单独html文件; 这个方式的好处多了取了,方便模板的统一管理,核心业务被单独分离出去;模板只完成显示任务;

前后端分离模式下的权限控制方案

ぐ巨炮叔叔 提交于 2019-11-27 23:56:06
在前后端分离的模式下,所有的交互场景都变成了数据交互,因此传统业务系统中的权限控制方案在前端已经不再适用(比如使用后台模板标签进行权限控制),需要另外设计权限控制方案。 权限控制的概念 要理解权限控制,需要明白两个概念:资源和权限。 资源: 对于一个系统来说,系统内部的所有信息都可以理解为是这个系统的资源。页面是资源、数据是资源、按钮是资源、图片也是资源。 权限: 权限就是访问某个资源所需要的标识。无论系统的权限如何设计,在用户登陆的时候都需要计算当前登陆用户所拥有的权限标识集合,这样才能确定这个用户所能访问的系统资源。 由上面可以得出,权限控制是控制登陆用户对于系统资源的访问。 前后端在权限控制中各自的职责 要弄清前后端在权限控制中各自的职责,需要明白前后端在系统中各自的职责。 服务端: 提供数据接口。 前端: 路由控制、页面渲染。 由于前端负责与用户交互,这就意味着,用户所能操作的资源入口就都是由前端进行控制,那么前端的权限控制就包括了前端路由的权限控制和页面内组件的权限控制。 前端路由的权限控制: 过滤非法请求,用户只能访问权限范围之内的页面资源。 页面内组件的权限控制: 根据用户的权限控制页面组件的渲染,包括各种按钮、表格和分割线等。 随着前端组件化的快速发展,用户所看到的一切都可以理解为组件。页面是一个大组件,其内部由各种小组件拼凑而来

前后端分离项目本地测试跨域问题配置

独自空忆成欢 提交于 2019-11-27 23:55:13
tomcat的web.xml添加 <filter> <filter-name>CorsFilter</filter-name> <filter-class>org.apache.catalina.filters.CorsFilter</filter-class> <init-param> <param-name>cors.allowed.origins</param-name> <param-value>*</param-value> </init-param> <init-param> <param-name>cors.allowed.methods</param-name> <param-value>GET,POST,HEAD,OPTIONS,PUT</param-value> </init-param> <init-param> <param-name>cors.allowed.headers</param-name> <param-value>*</param-value> </init-param> <init-param> <param-name>cors.exposed.headers</param-name> <param-value>Access-Control-Allow-Origin,Access-Control-Allow-Credentials<