前后端分离

1、自测时用的postman没有任何问题 2、和前端对接时发现登录不上,ajax Error 出错：{"readyState":0,"responseText":"","status":0,"statusText":"error"} 3.1、spingsecurity 配置允许跨域， .requestMatchers(CorsUtils::isPreFlightRequest).permitAll() 会存在用户变成匿名用户的问题 3.2 cors 配置类 @Configurationpublic class CorsConfig { private CorsConfiguration buildConfig() { CorsConfiguration corsConfiguration = new CorsConfiguration(); // 你需要跨域的地址 注意这里的 127.0.0.1 != localhost // * 表示对所有的地址都可以访问 corsConfiguration.addAllowedOrigin("*"); // 跨域的请求头 corsConfiguration.addAllowedHeader("*"); // 2 // 跨域的请求方法 corsConfiguration.addAllowedMethod("*"); // 3 //加上了这一句

前后端分离已经是老生常谈的话题了，甚至再谈前后端分离显得比较落伍。之所以想谈谈前后端分离，是因为在这种分工模式下实实在在的遇到了一些问题。这篇文章希望对前后端分离做一个简单的梳理。 尽管前后端的分离已经不再新颖，但仍然有很大一部分企业由于历史的原因，采用的是“传统”的Web开发模式，即前端人员根据UI做好HTML页面，再将HTML页面交给后端开发人员打通数据和调试。这是最为“原始”的方式，甚至有可能在如今的大学课堂中仍然是这样的教学方式。我想前端开发人员被“鄙视”也即是这样的开发模式所导致，因为前端几乎不做任何的调试，可能只是调整下页面的一些工作。这样的开发模式也很简单，看起来是对后端开发人员要求更高，也就是要求后端开发人员掌握一定的前端基础。 但随着前端的发展，一些年轻的公司或者年轻的项目也早已对前后端分离进行了实践，前端不再只写HTML页面，后端也不需要掌握前端JavaScript基础。因为在前后端分离的开发模式下，前端和后端被实实在在的所隔离，后端代码中不再将前端代码写到工程中，前端和后端只专注自己的领域，这样的开发模式但也带来了很多的问题。 后端开发人员不再参与到前端的开发，测试变得更加的抽象 以前后端开发人员写完一个功能，只需要启动程序，打开页面就能自测，这是一个很具体的也很容易的一个操作。但是在分离过后，前后端代码隔离独立部署

一、使用swagger2生成接口文档 依赖 <dependency> <groupId>io.springfox</groupId> <artifactId>springfox-swagger2</artifactId> <version>2.7.0</version> </dependency> <!-- swagger的bootstrap的美化界面 --> <dependency> 　　<groupId>io.springfox</groupId> <artifactId>springfox-swagger-ui</artifactId> <version>2.7.0</version> </dependency> 在springboot的启动类上加@EnableSwagger2注解 在controller的接口上加@ApiOperation(value = "用户查询服务")注解表明接口的作用。 swagger2中常用注解： @Api()：用在请求的类上，表示对类的说明，也代表了这个类是swagger2的资源 　　　参数：tags：说明该类的作用，参数是个数组，可以填多个。 　　　　　　value="该参数没什么意义，在UI界面上不显示，所以不用配置" 　　　　　　description = "用户基本信息操作" @ApiOperation()：用于方法

对于asp.net core 下的Swagger，之前一直用Swashbuckle的，因为官方推荐，再加上有老张的博客助力《 从壹开始前后端分离【 .NET Core2.0/3.0 +Vue2.0 】框架之三 || Swagger的使用 3.1 》，所以用起来很顺手，但Swashbuckle有个问题，一直没解决，就是如果你的网站不是部署在根目录的话，是部署IIS在虚拟应用程序下的话，那Swagger就用不了了，不知有没有朋友有解决的方法，后面我试用了NSwag，发现它可以用在虚拟应用程序下，也是微软官方推荐的，多方比对，就采用了NSwag.AspNetCore。 使用方法，很简单，按 微软官网介绍的入门方法 ，如下图 我这个博客基础的我就不写出来了，写几点常用功能 实现登录认证token的输入 现在的前后端分享项目，主要采用在header里添加token来进行身份认证，那如何在NSwag的Swagger上面实现这个功能呢。代码如下 services.AddOpenApiDocument(settings => { 　　settings.AddSecurity("身份认证Token", Enumerable.Empty<string>(), new NSwag.OpenApiSecurityScheme() 　　{ 　　　　Description = "JWT授权

1.概念 前后端分离已成为互联网项目开发的业界标准使用方式，通过nginx+tomcat的方式（也可以中间加一个nodejs）有效的进行解耦，并且前后端分离会为以后的大型分布式架构、弹性计算架构、微服务架构、多端化服务（多种客户端，例如：浏览器，车载终端，安卓，IOS等等）打下坚实的基础。 2.老的方式 1.产品经理/领导/客户提出需求 2.UI做出设计图 3.前端工程师做出html页面 4.后端工程师将html页面套成jsp页面(前后端强依赖，后端必须要等前端的html做好才能套jsp。如果html发生变更，就更痛了，开发效率低) 5.集成出现问题 6.前端返工 7.后端返工 8.二次集成 9.集成成功 10.交付 3.新的方式 1.产品经理/领导/客户提出需求 2.UI做出设计图 3.前后端约定接口&数据&参数 4.前后端并行开发（无强依赖，可前后端并行开发，如果需求变更，只要接口&参数不变，就不用两边都修改代码，开发效率高） 5.前后端集成 6.前端页面调整 7.集成成功 8.交付 4.前端技术架构 架构描述：以Node.js为核心的Vue.js前端技术生态架构 来源： https://www.cnblogs.com/itzlg/p/11854232.html

最近在开发，遇到前后端关于Boolean类型的参数传参和接收的问题: 场景：后台会根据用户是否出车/是否出司机（Boolean类型）来决定后端的业务逻辑（比如费用的计算），前端使用JSON字符串类型传输，后端使用@RequestBody接收对象... 前后端分离特殊内容规范 单选框、下拉框、复选框 由后端接口统一逻辑判定是否选中，通过isSelect标示是否选中，示例如下： { code: 200, data: { message: "success", list: [{ id: 1, isCarProvide: 1, isDriverProvide: 0 }] } } 规定：禁止下拉框、复选框、单选框判定选中逻辑由前端来处理，统一由后端逻辑判定选中返回给前端展示； Boolean类型参数的传值 关于Boolean类型，JSON数据传输一律使用 1/0 来标示，1为是/true，0为否/false，前端单选框/复选框表示boolean，后台使用boolean接收，前端value值使用true/false或者1/0都是可以自动转成boolean类型的，我做以下测试： Test实体类 @Data @AllArgsConstructor @NoArgsConstructor public class Test implements Serializable { private

什么是前后端分离，要区分前端和后端，需要有个明确的界限。一般，用户可以直接看到的东西，都是属于前端的范畴，除了前端之外都属于后端了。 在传统的像ASP，JSP和PHP等开发模式中，前端是处在一个混沌的状态中，可以说是没有独立的“人格”可言。 前端负责切图和编写静态页面模板，后端将数据渲染到前端提供的页面模板中，最后将页面渲染到浏览器展示。 这个过程中，前端只提供页面模板或者写一些JavaScript脚本，有的甚至JS脚本都是后端来写，前端的作用只局限于切图和样式模板文件，这种角色就是传说中的“切图仔”。 这也是为什么行业内都觉得前端是一个很简单的工作，只要花个一周，学下HTML、CSS和PS的简单技巧就可以胜任的工作。 现在看来，那时候的前端就是一个打酱油的，发展前景很有限。那时候的JavaScript脚本也比较简单，一个jQuery就可以横扫天下，所以对于精通语言类代码的后端程序员来说，可以很快的上手JavaScript，对前端来说，发展空间就更小了。 前后端分离，不只是简单的代码的分离。 首先是要架构上分离解耦，逐渐摆脱前后端在架构上的依赖，前后端各司其职，分开部署在不同的服务器上，通过RESTful接口传递数据。减轻后端服务器的压力，后端服务器不再负责页面渲染，只负责输入数据，吞吐量提升了好几倍。 其次是逻辑分离，不分离的时候，对于业务代码的界限很不明确

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

本教程将从零开始部署一个 前后端分离 的开源项目，利用docker虚拟机的容器技术，采用分布式集群部署，将项目转换成为高性能、高负载、高可用的部署方案。包括了MySQL集群、Redis集群、负载均衡、双机热备等等。 部署图 所用到的主流技术 Docker 容器、前后端集群、MySQL集群、Redis集群、Haproxy负载均衡、Nginx负载均衡、Keepalived实现双机热备 前后端分离项目部署图 前后端分离项目开源框架介绍 本次教程所采用的 前后端分离 的项目开源框架是人人网的renren-fast，前台开发语言采用Vue，后台是java。 总体部署方案概述 数据库我们采用的是集群，每一个MySQL节点都是要发布到一个 Docker 虚拟机实例中（实例就是一个虚拟的空间，或者叫容器），每一个MySQL都要部署到独立的容器里面，这些MySQL之间有一个集群环境。 然后我们不能把所有的数据库的请求都定向给一个MySQL去处理，因为这样负载会很高，所以我们应该分散MySQL的处理数据的请求，那么我们该怎么做呢？ 答案就是做一个负载均衡，后台程序发给数据库所有的请求都由负载均衡分散给其余的MySQL，这些MySQL就能去处理对应的请求了，这样每一个MySQL节点的负载相应的会低一点。 而后台项目要体现的就是高可用，任何一个节点挂掉后不影响整体的运行，所以后台项目也要搞集群

servlet中设置响应方式 // set header response .addHeader ( "Access-Control-Allow-Origin" , "*" ) ; response .setContentType ( "text/html;charset=utf-8" ) ; // parse req String reqJSON=StreamUtils .getStr (request .getReader ()) ; // service IProductService ps = new ProductServiceImpl() ; String respJson = ps .findAllRespJson (reqJSON) ; // resp response .getWriter () .write (respJson) ; jquery中ajax基本格式 function loadJson () { var reqJson = { "opr" : "findAll" }; //parse req var reqJsonStr = JSON .stringify(reqJson); $.ajax({ async: false , type: "POST" , url: "http://localhost:8080/store/products" ,