前后端分离方案及技术选择
1.什么是前后分离？
理解前端分离可以从三个方面来理解:
1.互动形式
2.代码组织形式
3.开发模式和流程
1.1互动形式
前端和后端没有分开
后端组装并呈现数据和页面后，输出最终的html到浏览器。浏览器收到后会解析html，解析导入的css，执行js脚本，完成最终的页面显示。
前后分离
后端只需要和前端就接收和返回的数据格式(一般是JSON格式)达成一致，并为前端提供API接口。前端可以通过HTTP请求调用API进行交互。前端获取数据后，对页面进行组装和渲染，最终呈现在浏览器中。
1.2代码组织形式
前端和后端没有分开
web应用早期，前端页面和后台业务数据处理的代码都放在一个项目下，甚至在同一个目录下，前端页面和后端代码混在一起。前端和后端开发工程师都需要将整套代码导入到开发工具中进行开发。现阶段前端代码和工作耦合度太高，前端无法独立开发和测试，后端人员完成页面后也要依赖前端完成开发。最坏的情况是前端工程师需要了解后端模板技术(jsp)，后端工程师需要了解前端技术，需要口头讲解页面数据接口来配合开发。否则前端只能是“剪影”，只输出HTML、CSS、少量与业务逻辑无关的JS；然后从后端转化到后端jsp，业务的js代码也写好了。
前后分离
前端代码和后端代码放在不同的项目中，前端代码可以独立开发，后端API服务可以通过mock/easy-mock技术独立运行和测试。后端代码也可以独立开发、运行和测试。通过swagger技术，可以自动生成API文档供前端读取，并进行自动接口测试，保证API的可用性，降低集成风险。
1.3开发模式和流程
前端和后端没有分开
在项目开发阶段，前端根据原型和UI设计稿，编译与业务无关的HTML、CSS和少量js(纯效果的)，交给后台人员，后台人员将HTML变成jsp，通过JSP的模板语法进行数据绑定和一些逻辑操作。后台完成后，将所有代码，包括前端代码和后端代码，打包成一个war，然后部署到同一个服务器上运行。最多做个动静分离，就是把图片，css，js分别部署到nginx。
具体开发流程如下:素描。
前后分离
前端和后端分离后，前端根据原型和UI设计稿编写与业务无关的HTML、CSS和少数js(纯效果的)，后端也根据原型设计API，并在API数据规范上与前端达成一致。等到后台API完成，或者刚好在API数据规范设置完成之后。前端可以通过HTTP调用API，也可以通过模拟数据完成数据组装和业务逻辑编写。前后端可以平行，也可以先发展前端后发展后端。
具体开发流程如下:素描。
二、前后分离的利弊。
对比以上三个方面，前端分离架构相比传统的web架构有了很大的改变，看起来有很多好处。分不分，还是要理性分析是否值得做。
从目前应用软件开发的发展趋势来看，主要有两个方面需要注意:
越来越注重用户体验。随着互联网的发展，开始多终端化。
大型应用架构模式正在向云、微服务方向发展。
我们主要通过前后端分离架构在以下四个方面进行改进:
为优质产品建立一个精益团队
通过分离开发团队的前端和后端，前端和后端工程师只需要专注于前端或后端的开发工作，让前端和后端工程师实现自主性，培养自己独特的技术特点，进而构建全栈精益开发团队。
提高开发效率
前端和后端分离后，前端和后端代码可以解耦。只要前端和后端进行沟通，并就应用所需的接口和接口参数达成一致，就可以开始并行开发，而不必等待对方的开发工作结束。同时，即使需求发生变化，只要接口和数据格式不变，后端开发人员也不需要修改代码，只要前端发生变化即可。这样整个应用的开发效率会有质的提升。
完美应对复杂多变的前端需求
如果开发团队能够完成前端和后端分离的改造，建设优秀的前端和后端团队，独立开发，让开发者专注于专业化，开发能力必然会得到提升，能够完美应对各种复杂多变的前端需求。
增强代码的可维护性
前端和后端分离后，应用代码不再混合，只有运行时才会有调用依赖。应用程序代码将变得整洁清晰，代码阅读和代码维护都将比以前更容易。
那么前后端分开有什么问题呢？没想到后端工程师会变得无所不能，除非你说前端团队会配备。。。
第二，前端和后端分离的架构方案。
要把前后端分开，主要是前端的技术架构发生了很大的变化，后端主要换成了restfull风格的API，再加上Swagger技术自动生成在线界面文档就差不多了。
目前，前端和后端分离方案主要有两种前端技术架构:
传统水疗
服务器端呈现SSR
2.1传统水疗
传统的SPA是指单页面应用，即整个网站只有一个页面，所有功能都通过这个页面呈现。因为一个人的肉眼是在某个时间点看一个页面的，所以为什么需要做多个不同功能的页面呢？只需保留一个页面作为模板，然后通过路由跳转来更新这个模板页面的内容。的确，现在通过reac family bucket、tvue family bucket、模块化、路由、wabpack等技术可以轻松实现一个单页面的应用。
单页应用程序的运行过程
1.用户通过浏览器访问网站url。
2.将单页html文件(index.html)下载到浏览器，然后下载html中引用的css和js。
3.将3.css和js下载到浏览器后，浏览器开始解析并执行js向后端服务异步请求的数据。
4.请求的数据完成后，数据被绑定和呈现，最后一个完整的页面呈现在用户的浏览器中。
2.2服务器渲染
服务器端渲染的方案就是数据绑定和渲染都在服务器端完成，服务器输出最终的html给浏览器。看完这个，你有问题吗？这不是又到了前后端不分离的时代了吗？答案是否定的，因为这里的服务器是用来进行前端数据绑定和渲染的，也就是把浏览器的一部分工作分享给服务器。目前具备这种能力的服务器是NodeJs服务器。
它的原理其实就是在浏览器和前端代码之间插入一个NodeJs服务器。当浏览器请求前端页面时，首先会经过NodeJs服务器，NodeJS会读取前端页面，并执行异步后端API。在获取数据后，它会做页面数据绑定、渲染等工作，完成一个最终的html然后返回给浏览器，最后由浏览器显示出来。
服务器端渲染应用的运行过程:
1.用户通过浏览器访问网站url。
2.Nodejs服务器接收请求，读取相应的前端html、css和js。
3.Nodejs解析并执行js，从后端API异步请求数据。
4.4后。NodeJs请求完成数据，它被绑定并呈现以获得最终的html。
5.NodeJs向浏览器输出html，浏览器显示。
PS:其实本质就是把前端写成nodeJs服务器端web应用。实现服务器端渲染后，我们最后运行一个Nodejs服务器端应用。单页面应用程序是将静态页面部署到静态资源服务器上运行。
看到这里，你还有什么问题吗？为什么要麻烦服务器端渲染呢？
2.3 SPA和服务器渲染方案比较
SPA的优点是开发和部署简单。缺点是首次加载缓慢，需要更好的网络和不友好的搜索引擎优化。
所以，以下是使用服务器端渲染的原因(摘录vue官方说法):
与传统的SPA(单页应用)相比，服务器端渲染(SSR)具有以下优势:
更好的SEO，因为搜索引擎爬虫可以直接查看完全渲染的页面。
请注意，到目前为止，Google和Bing可以很好地索引同步的JavaScript应用程序。同步是这里的关键。如果您的应用程序最初显示加载菊花图，然后通过Ajax获取内容，爬行工具将不会在爬行页面内容之前等待异步完成。也就是说，如果SEO对你的站点非常重要，你的页面异步获取内容，你可能需要服务器端渲染(SSR)来解决这个问题。
更快的内容获取时间，特别是对于慢速网络条件或慢速设备。
在显示服务器呈现的标记之前，您不必等待下载并执行所有JavaScript，因此您的用户将更快地看到完全呈现的页面。一般来说，它可以产生更好的用户体验，对于那些内容时间与转化率直接相关的应用程序，服务器端渲染(SSR)非常重要。
使用服务器端呈现(SSR)时有一些权衡:
受发展条件限制。特定于浏览器的代码只能在一些生命周期钩子函数中使用；某些外部库可能需要特殊处理才能在服务器渲染应用程序中运行。
与构建设置和部署相关的更多要求。与可以部署在任何静态文件服务器上的完全静态的单页应用程序(SPA)不同，服务器呈现应用程序需要位于Node.JSServer的运行环境中。
更多的服务器端负载。在Node.js中渲染一个完整的应用，显然比只提供静态文件的服务器占用更多的CPU资源(CPU密集型-CPU密集型)，所以如果你期望在高流量环境下使用，请准备好相应的服务器负载，明智地采用缓存策略。
以vue为例。服务器端渲染请参考官方指南:/Chris fritz/prerender-spa-plugin。
三、前后端分离技术选择
-artTemplate+bootstrap(不推荐，不完全前端分离)
-vue系列铲斗(推荐)
-react family bucket(推荐，生态)