前后端分离

参考资料：前后端分离架构概述(https://blog.csdn.net/fuzhongmin05/article/details/81591072)

一、背景

    前后端分离的核心思想是前端HTML页面通过Ajax调用后端的RESTFUL API 接口并使用JSON数据进行交互。

    Web服务器：一般指像Ngnix，Apache这类服务器，只能解析静态资源。

    应用服务器：一般指向Tomcat,Jetty,Resin这类既可以解析动态资源也可以解析静态资源，但解析静态资源的能力没有web服务器好。

    一般都是只有web服务器才能被外网访问，应用服务器只能内网访问。

二、未分离时代(各种耦合)

    这个时期的开发方式有两种：

   方式一： 前后端并行(前端根据设计图做成html页面、后端开发服务接口），然后后端将html改成jsp，并和服务接口集成，最后测试上线

   方式二：后端先开发服务接口，前端根据后端服务直接写模板，然后测试上线。

    方式二已经逐渐被淘汰，原因有二：第一，前端严重依赖后端，后端没有完成，前端完全没法干活。第二，由于趋势问题，会JSP，懂velocity，freemarker等模板引擎的前端越来越少。

    方式一至今还有一些小公司在用，方式一和方式二具有的共同缺点有三个：第一，前端无法单独调试，开发效率低。第二，前端会不可避免的遇到后台代码。第三，JSP本身所导致的一些问题。比如，JSP第一次运行会比较缓慢；在JSP有很多内容时，页面相应会很慢。

三、半分离时代

    前端负责开发页面，通过接口Ajax获取数据，采用DOM操作对页面进行数据绑定，最终是由前端把页面渲染出来。

    为什么说是半分离的？因为不是所有页面都是单页面应用，在多页面应用的情况下，前端因为没有掌握controller层，前端需要跟后端讨论，我们这个页面是要同步输出呢，还是异步渲染？而且这个时期通常也是一个工程师搞定前后端的所有工作，所以只能算半分离。

    这种方式的优点很明显。前端不会嵌入任何后端代码，能够模拟JSON数据来渲染页面。发现bug也能迅速定位是谁的问题。

    也还存在明显的弊端。第一，JS存在大量冗余，业务复杂时页面渲染部分的代码会非常复杂。第二，json返回的数据量比较大时，页面渲染会很慢，页面会卡顿。第三，搜索引擎的爬虫无法识别异步数据，SEO非常不方便。第四，资源消耗严重，业务复杂时一个页面要发起多次http请求才能将页面渲染完毕，PC端可能还好，但是移动端会非常消耗资源。

四、分离时代

    大家一致认同的前后端分离的例子就是SPA(single-page application)，所有用到的数据都是后端通过异步接口提供，前端只管展现。从某种意义上说，SPA确实做到了前后端分离，但是这种方式存在两个问题：第一，web服务中，SPA类占的比例很少。很多场景还有同步/同步+异步混合的模式，SPA不能作为一种通用的解决方案。第二，现阶段的SPA开发模式，接口通常是按照展现逻辑来提供的，而且为了提高效率我们也需要后端帮我们处理一些展现逻辑，这就意味着后端还是涉及了view层的工作，不是真正的前后端分离。

    SPA式的前后端分离，从物理层做区分，认为只要是客户端的就是前端的，服务器就是后端的。这种分法已经无法满足前后端分离的需要，我们认为从指责上划分才能满足目前的使用场景，前端负责view和controller层，后端只负责model层，业务处理与数据持久化等。

    在前后端彻底分离这一时期，前端的范围被扩展，controller层也被认为属于前端的一部分。在这一时期：前端负责view和controller层，后端只负责model层，业务/数据处理等。前端的controller层如何实现呢？node.js。node适合运用在高并发、I/O密集、少量业务逻辑的场景。

    可以就把nodeJS当成跟前端交互的api。

    浏览器(webview)不再直接请求JSP的API，而是：(1)浏览器请求服务器端的NodeJS. (2)NodeJS再发起HTTP去请求JSP。(3)JSP依然原样API输出JSON给NodeJS。(4)NodeJS收到JSON后再渲染出HTML页面。(5)NodeJS直接将HTML页面flush到浏览器。这样浏览器得到的就是普通的HTML页面，而不用再发Ajax去请求服务器了。