前后端分离

前后端分离实践有感 前后端分离并不是什么新鲜事，到处都是前后端分离的实践。然而一些历史项目在从一体化 Web 设计转向前后端分离的架构时，仍然不可避免的会遇到各种各样的问题。由于层出不穷的问题，甚至会有团队质疑，一体化好好的，为什么要前后端分离？ 说到底，并不是前后分离不好，只是可能不适合，或者说……设计思维还没有转变过来…… 一体式 Web 架构示意 前后分离式 Web 架构示意 为什么要前后端分离 比为什么要前后端分离更现实的问题是什么时候需要前后端分离，即前后端分离的应用场景。 说起这个问题，我想到了 2011 年左右，公司在以 .NET 开发团队为主的基础上扩展了 Java 团队，两个团队虽然是在做不同的产品，但是仍然存在大量重复性的开发，比如用 ASP.NET WebPage 写了组织机构相关的页面，用 JSP 又要再写一遍。在这种情况下，团队就开始思考这样一个方案：如果前端实现与后端技术无关，那页面呈现的部分就可以共用，不同的后端技术只需要实现后端业务逻辑就好。 方案根本要解决的问题是把数据和页面剥离开来。应对这种需求的技术是现成的，前端采用静态网页相关的技术，HTML + CSS + JavaScript，通过 AJAX 技术调用后端提供的业务接口。前后端协商好接口方式通过 HTTP 提供，统一使用 POST 谓词。接口数据结构使用 XML 实现，前端 jQuery

【session问题---跳坑+爬坑】 session基础点： 1、session是会话控制。session对象储存特定用户会话所需的属性或者配置信息。当用户在该应用程序的web页面之间跳转时，session对象便会在一直存在。 2、session对象在客户端向服务端发起请求时，由服务端创建。 3、会话状态仅在支持cookie的浏览器中保留。 【重点】 （1）在同一个浏览器下，session是唯一的。 （2）session由服务端创建，不同的服务端（ip、域名、端口任意不同）之间的session不相同，它是不共享session的。 （3）服务端在创建session对象的同时，会生成一个session的唯一标识，这就是JSessionID。所以不同的服务端之间的JSessionID不同。 （4）JSessionID作为session的唯一标识，以cookie的形式返回给客户端，而在服务端以内存的形式保存。 【问题】 （1）session覆盖：当在浏览器上同时访问两个或者多个服务端时，由于不同的服务端之间不共享session，并且浏览器只有一个session，所以会出现session覆盖的问题。 表现：轮流访问服务端A、B时，JsessoinID每次都是不一样的。 第一次进入浏览器访问serverA，A服务端中并没有session存在，则由A生成JSessionID_A

我理解的Web开发前后端分离有两个维度 　　一种是：前端代码和后端代码分离。这个维度的前后端分离几乎全部实现了，应该没有多少在用jsp了吧。。。。 　　一种是：部署方式前后端分离 目前使用过的实现方式： 　　后段代码部署在tomcat中，前端代码使用FIS。在Nginx关联前后端代码。 　　后段代码部署在tomcat中，前端代码使用Node.js+vue 来源： https://www.cnblogs.com/danielJinyu/p/11364094.html

这些天对前后端做了一个全面的研究，给大家分享下前后端分离应用的俩种模式，以及如何应用到实际场景，以及他落地的注意点； 现状 　　前后端分离开发已经成为行业标准。 　　他主要是通过web服务器(Nginx || Nodejs ...) + 应用服务器（Tomact ...）前后两个服务端进行有效解耦而达到前后端分离的效果。 　　技术核心思想：前端通过js创建HTTP请求调用后端服务的Restful API接口并返回JSON数据进行交互 　　web服务器：一般指像Nginx，Node这类的服务器，他们一般只适合解析静态资源和处理一些简单的控制以及业务逻辑； 　　应用服务器：一般指像Tomcat，Jetty这类的服务器可以解析动态资源也可以解析静态资源，但解析静态资源的能力没有web服务器好； 　　他存在的主要目的就是把项目的开发工作做到更细化，更专业化。 　　前后端分离模式也是让前端这个职位快速崛起的原因之一。 发展史 　　以前的程序员没有前后端之分，所有项目基本都是一个程序员既当爹又当妈的，一把全包了，最多分配一个页面仔配合后端工作。期间很多企业慢慢发现随着市场的发展，客户端的体验达不到要求。必须要请专人来做客户端这块的体验优化，而那时候还没这类专业人士（或者说是珍稀物种）那请一个成本可不小。 　　这时公司领导就找当时的程序员谈话了，想要他们接下这活，但发现他们大都嫌弃这活又脏又累

首先我是很赞同业界的前后端分离的开发模式，虽然现在都讲究全栈工程师，但是毕竟术业有专攻，前端同学专注多终端，后端同学关注高性能高可用。大家各自再自己的专注点上发光发热。 想想我们以前分模块开发，既写java又写jsp，高级点的jsp不写逻辑，所有的交互都是异步交互，算是一个简单的前后端分离模型，最后找个美工（对，不是前端是写css或者会画图的美工画两个图）美化一下，然后就可以用起来了，这样的模式简直就是原始社会一样。 目前我同时接手了前后端同学给我的2份代码后，一个人做起了前后端分离开发，我感觉自己一下子高大上了起来，但是有几点我也要吐槽一下 1我要维护2分代码，一份用webstorm编译js代码，一份用intelidea开发编译java代码，同时开了java和node服务本地联调，这2个服务光开起来就已经7G内存了（jvm我开的是1024M，因为需要加载对象内存处理）。可怜的X1的内存是焊死的...焊死的....，而且只有8G....基本再开chrome就卡死了，卡死了。。。 2 本地开发模式是这样的，前端代码用node开启一个server跑页面，后端代码开启跑接口服务，用页面调用后端的接口服务，这就遇到一个尴尬的js跨域调用服务的问题，还好chrome良心支持这个参数，又还好IE我们已经放弃了。。。 "C:\Program Files (x86)\Google\Chrome

前后端分离是现在互联网项目开发的业界标准使用方式，我们来看看它的发展。 前后端未分离时代（各种耦合） 这个时代可以叫做MVC时代，因为主要是使用MVC框架。 大致就是，所有的客户端请求都被发送给作为控制器的Servlet，它接收请求，并根据请求信息将它们分发给适当的JSP来响应。同时，Servlet还根据JSP的需求生成JavaBeans的实例并输出给JSP环境。JSP可以通过直接调用方法或使用UseBean的自定义标签得到JavaBeans中的数据。需要说明的是，这个View还可以采用Velocity、Freemarker等模板引擎。使用了这些模板引擎，可以使得开发过程中的人员分工更加明确，还能提高开发效率。 在这个时期，首先是有以下的开发方式。 这种方式已经逐渐淘汰。主要原因有两点： 1.前端在开发过程中严重依赖后端，在后端没有完成的情况下，前端根本无法干活。 2.由于趋势问题，会JSP、懂Velocity和晓Freemarker等模板引擎的前端越来越少。 因此进化出了另一种开发方式，这种方式现在很多小型传统软件公司还在使用。 但是这种开发方式和它前身的开发方式有着同样的缺点： 1.前端无法单独调试，开发效率低。 2.前端不可避免会遇到后台代码，比如说JSP中的EL表达式和JSTL标签，难为前端。这种方式的耦合性太强，就算用了Freemarker等模板引擎

前后端不分离 在前后端不分离的应用模式中，前端页面看到的效果都是由后端控制，由后端渲染页面或重定向，也就是后端需要控制前端的展示，前端与后端的耦合度很高。 这种应用模式比较适合纯网页应用，但是当后端对接App时，App可能并不需要后端返回一个HTML网页，而仅仅是数据本身，所以后端原本返回网页的接口不再 适用于前端App应用，为了对接App后端还需再开发一套接口。 请求的数据交互如下图: 前后端分离 在前后端分离的应用模式中，后端仅返回前端所需的数据，不再渲染HTML页面，不再控制前端的效果。至于前端用户看到什么效果，从后端请求的数据如何加载到前端中，都由前端自己决定，网页有网页的处理方式，App有App的处理方式，但无论哪种前端，所需的数据基本相同，后端仅需开发一套逻辑对外提供数据即可。 在前后端分离的应用模式中 ，前端与后端的耦合度相对较低。 在前后端分离的应用模式中，我们通常将后端开发的每个视图都称为一个接口，或者API，前端通过访问接口来对数据进行增删改查。 对应的数据交互如下图 : 来源： https://blog.csdn.net/DDD_QQQ/article/details/99223013

1、背景 前后端分离已成为互联网项目开发的业界标准使用方式，通过nginx+tomcat的方式（也可以中间加一个nodejs）有效的进行解耦，并且前后端分离会为以后的大型分布式架构、弹性计算架构、微服务架构、多端化服务（多种客户端，例如：浏览器，车载终端，安卓，IOS等等）打下坚实的基础。这个步骤是系统架构从猿进化成人的必经之路。 核心思想是 前端HTML页面通过AJAX调用后端的RESTFUL API接口并使用JSON数据进行交互 。 Web服务器：一般指像Nginx，Apache这类的服务器，他们一般只能解析静态资源； 应用服务器：一般指像Tomcat，Jetty，Resin这类的服务器可以解析动态资源也可以解析静态资源，但解析静态资源的能力没有web服务器好； 一般都是只有web服务器才能被外网访问，应用服务器只能内网访问。 以前的Java Web项目大多数都是Java程序员又当爹又当妈，又搞前端，又搞后端。随着时代的发展，渐渐的许多大中小公司开始把前后端的界限分的越来越明确，前端工程师只管前端的事情，后端工程师只管后端的事情。正所谓术业有专攻，一个人如果什么都会，那么他毕竟什么都不精。大中型公司需要专业人才，小公司需要全才，但是对于个人职业发展来说，前后端需要分离。 2、未分离时代（各种耦合） 早期主要使用MVC框架，Jsp+Servlet的结构图如下： 大致就是

前言 　　很久没写文章了，今天有时间，把自己一直以来想说的，写出来，算是一种总结吧！ 这篇文章主要说前后端分离模式下(也包括app开发)，自己对后台框架和与前端交互的一些理解和看法。 　 前后端分离，一般传递json数据，对于 出参 ，现在通用的做法是，包装一个响应类，里面包含code，msg，data三个属性，code代表状态码，msg是状态码对应的消息，data是返回的数据。 　　如 {"code":"10008","message":"手机号不存在","totalRows":null,"data":null} 　　对于入参，如果没有规范，可是各式各样的，比如： 　　UserController的getById方法，可能是这样的： 　　　　 　　　　如果是把变量放在url，是这样的： 　　　　 　　比如 addUser方法，如果是用user类直接接收参数，是这样的： 　　 　　这样在前后端不分离的情况下，自己前后端代码都写，是没有啥问题，但是前后端分离情况下，如果这样用user类接收参数，如果你用了swagger来生成接口文档，那么，User类里面的一些对于前段来说没用的字段（createTime、isDel、updateTime。。。），也都会给前端展示出来，这时候前端得来问你，哪些参数是有用的，哪些是没用的。其实每个接口，对前端没用的参数，最好是不要给他展示，所以

一、前言 对目前的web来说，前后端分离已经变得越来越流行了，越来越多的企业/网站都开始往这个方向靠拢。前后端分离概念在今天其实并不新鲜，自以MVC模型为主的开发模式流行之初，前后端分离思想就被提出来了，但是经历了几十年的发展，前后端分离并没有得到实质的进步和应用。得益于前后端框架的丰富和发展以及接口文档自动化技术的出现，前后端分离于最近几年在很多的实践中得到了越来越好的应用和推崇。那么，什么是前后端分离呢？为什么要选择前后端分离呢？前后端分离对实际开发有什么好处呢? 二、背景 在以前传统的网站或者系统开发中，前端的工作一般只是切图，简单的将UI设计师提供的原型图实现成静态的HTML页面。而具体的页面交互逻辑，如页面与数据的交互工作等，可能都是由后台开发人员来实现，或者是前端紧紧的耦合后台。比如以前的基于MVC架构的淘宝Web，架构决定了前端只能依赖后台，这种模式是前端写好静态demo，后端翻译成VM模板，同时后台还实现C层的逻辑。 更有甚者，部门公司后台人员直接兼顾前端工作，一边实现API接口，一边开发页面。这导致后台的开发压力大大增加。前后端工作分配不均。不仅仅开发效率慢，而且代码维护困难。而前后端分离，则可以很好的解决前后端分工不均的问题。将更多的页面交互逻辑分配给前端来处理，而后端则可以专注于其本职工作，比如提供API接口，进行权限控制以及进行运算等工作