前后端分离开发：后端可以独立于前端单独开发，前端也可以独立于后端单独开发，互不影响,按照API文档进行开发。


首先必须先规定好接口文档
后端按接口文档提供接口
前端按接口文档调用接口

	

本文作者：忧郁的马赛克
原文地址：https://www.cnblogs.com/shanrengo/p/6397734.html
关于前后端分离，松哥之前写过几篇文章来和大家聊这个问题：
一个Java程序猿眼中的前后端分离以及Vue.js入门
Spring Boot + Vue 前后端分离，两种文件上传方式总结！
Spring Boot + Vue 前后端分离开发，前端网络请求封装与配置
Spring Boot + Vue 前后端分离开发，权限管理的一点思路
也做过几个开源的 Spring Boot + Vue 前后端分离的项目：
微人事
V部落
但是毕竟要从前后端不分变为前后端分离，思维的变化还是比较大的，因此，今天我们就再来说说一说这个话题。
为什么要分离
如果只问“前后端分离的意义大么？”这是废话，因为从软件架构的角度 Web 的前后端从一开始不就一直是分离的么，而且 browser、server 可能将永远分离下去。
为了了解这个问题，我们有必要先了解一下 Web 的研发模式演变，关于这个题材，下面这篇博文说得不错，这边就不做搬运工了。
https://github.com/lifesinger/blog/issues/184
我们不能“为了分离而分离”，而应该“为了真正理解 web 开发、为了更好完成需求而分离”。
前后端分离实践
前端人员配备是否充足？
由于所在公司以往项目采用传统开发风格，即以后端 MVC 为主的开发模式，前端人员仅仅提供静态 html 页面，其余工作皆由后端开发人员完成。采用前后端分离模式可以减后台负担，加快研发效率，当然，前提是前端能做好的话。
以往只需要提供静态页面的前端人员，在前后端分离模式中要负责项目的 view+controller 部分，即除了静态页面，还需要负责页面的所有交互代码、以及 nodejs 与视图层以及后端 API 的交互工作，无疑增加了前端人员的学习成本，在没有足够知识和人才储备的情况下，只能让前端人员加班加点。
前后端职责分配
很多公司认为采用前后端分离之后，前后端只需要通过指定 API 进行交互即可，前端负责页面渲染， Nodejs 负责路由分配，后端提供 API 。忽视了大量关键工作，职责分配和细节处理没有相应文档规定，缓存机制、图片上传下载、数据校验、语言国际化等等并没有出具相应信息。另外，大量忽视了 nodejs 层的作用，仅仅把 nodejs 当成一个路由中转，这一方面也是对 nodejs 技术的不熟悉导致的，其实 nodejs 能负责很多事，除了复杂业务逻辑处理和数据操作由 Java 负责，大量工作完全可以在 nodejs 层处理。
后端 API 是否 RESTFul 风格？
很多公司采用了前后端分离模式后，后端 API 仍然采用以往的传统风格，这是不合理的。
RESTFul 风格的 API 应该是前后端分离的最佳实践。RESTFul 推荐每个 URL 能操作具体的资源,而且能准确描述服务器对资源的处理动作，通常服务器对资源支持 get/post/put/delete/ 等，用来实现资源的增删改查。
前后端分离的话，这些 api-url 是对接的桥梁，采用 RESTFul 接口地址含义才更清晰、见名知意。
前后端协作模式
前后端分离后，无论是 API 接口的对接还是测试工作，都涉及到前后端人员的沟通，很多公司采用前后端分离后，前后端协作模式配合力度低，互相等待，开发效率低下，反而不如传统的开发模式。例如：当后端 API 没有编写完成时，前端无法进行调试，这就导致了前端会被后端阻塞的情况。其实像这种互相等待的模式需要改进， Mock Server 可能可以解决一些问题。
如何前后端分离？
怎么做前后端分离？大方向就是
后端专注于：后端控制层( RESTFul API) & 服务层 & 数据访问层。
前端专注于：前端控制层(Nodejs) & 视图层
本人认为的前后端分离模式应该是这样：
项目设计阶段，前后端架构负责人将项目整体进行分析，讨论并确定 API 风格、职责分配、开发协助模式，确定人员配备；设计确定后，前后端人员共同制定开发接口。
项目开发阶段，前后端分离是各自分工，协同敏捷开发，后端提供 RESTFul API，并给出详细文档说明，前端人员进行页面渲染。前端的任务是发送API请(GET,PUT,POST,DELETE 等)获取数据(json，xml)后渲染页面。
项目测试阶段， API 完成之前，前端人员会使用 mock server 进行模拟测试，后端人员采用 junit 进行 API 单元测试，不用互相等待；API 完成之后，前后端再对接测试一下就可以了，当然并不是所有的接口都可以提前定义，有一些是在开发过程中进行调整的。
项目部署阶段，利用 nginx 做反向代理，即 Java + nodejs + nginx 方式进行。
结语
从经典的 JSP+Servlet+JavaBean 的 MVC 时代，到 SSM(Spring + SpringMVC + Mybatis)和 SSH(Spring + Struts + Hibernate)的 Java 框架时代，再到前端框架(KnockoutJS、AngularJS、vueJS、ReactJS)为主的 MV* 时代，然后是 Nodejs 引领的全栈时代，技术和架构一直都在进步。虽然“基于 NodeJS 的全栈式开发”模式很让人兴奋，但是把基于 Node 的全栈开发变成一个稳定的、让大家都能接受的东西还有很多路要走。创新之路不会止步，无论是前后端分离模式还是其他模式，都是为了更方便的解决需求，但它们都只是一个“中转站”。
走过的“中转站”可能越来越多，但是不要渐行渐远才是。
●分布式数据库中间件 MyCat 搞起来！
●What？Tomcat 竟然也算中间件？
●我的第一本书，被选作大学教材了！
●北冥有 Data，其名为鲲，鲲之大，一个 MySQL 放不下！
●MySQL 只能做小项目？松哥要说几句公道话！
●松哥整理了 15 道 Spring Boot 高频面试题，看完当面霸！
●想让自己的项目6666，可是 Chrome 不答应！
●干货|最新版 Spring Boot2.1.5 教程+案例合集
●极简 Spring Boot 整合 Thymeleaf 页面模板
●Spring Boot 中 10 行代码构建 RESTful 风格应用
你点的每个在看，我都认真当成了喜欢

前后端分离开发已成为业界的共识，但分离的同时也带来了部署的问题。传统web模式下，前端和后端同属一个项目，模板的渲染理所当然由后端渲染。然而随着node的流行，以及webpack的模块化打包方案，让前端在开发阶段完全有能力脱离后端环境：通过本地node启动一个服务器，搭配Mock数据，马上就可以进行业务开发了。
但是到了部署阶段，问题也就显现出来：前端最后打包出来的js，css以及index.html，到底放在哪里？静态文件js，css或者图片，我们还可以在CI阶段上传到cdn服务器上，但是最后的html模板index.html一定需要放在一个服务器上，然而这个服务器到底由前端还是后端维护？
前端维护HTML
如果html模板由前端维护，那么前端就需要自己使用一个静态服务器：提供HTML的渲染和API接口的转发。常见的单页应用，也是推荐使用Nginx进行部署。
使用Nginx部署，这里又分两种情况： 
 静态资源完全由Nginx托管，也就是js,css和index.html放在同一个dist目录里。在这种情况下，webpack的publicPath一般不用特别设置，使用默认的/即可 
 静态资源上传CDN，Nginx只提供index.html。在这种情况下，webpack的publicPath要设置成cdn的地址，例如://static.demo.cn/activity/share/。但这又会引发一个问题，由于qa环境，验证环境，生产环境的cdn地址通常不同，为了让index.html可以引入正确的静态文件路径，你需要打包三次，仅仅为了生成三份引用了不同路径的html(即使三次打包的js内容完全一样)
nginx配置
server {
    listen       80;
    server_name  localhost;

    location / {
        root   /app/dist; # 打包的路径
        index  index.html index.htm;
        try_files $uri $uri/ /index.html; # 单页应用防止重刷新返回404，如果是多页应用则无需这条命令
    }

    location /api {
        proxy_pass https://anata.me; #后台转发地址
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_set_header   X-Real-IP         $remote_addr;
    }
}
理论上qa，yz，prod环境的接口转发地址也不同，因此你还需要三份nginx.conf配置
后端维护HTML
很多情况下，我们需要渲染的页面带上后端注入的动态数据，又或者页面需要支持SEO，这种情况下，我们只能把模板交给后端渲染。那么后端维护的html模板怎么获取打包后的hash值呢？ 
前端打包后的index.html直接发给后端(简单粗暴，并不推荐)  
前端打包时通过插件webpack-manifest-plugin后生成一个manifest.json文件，该文件其实是个key-value的键值对，key代表了资源名称，value记录了资源的hash
{
  "common.css": "/css/common/common-bundle.804a717f.css",
  "common.js": "/js/common/common-bundle.fcb76db9.js",
  "manifest.js": "/js/manifest/manifest-bundle.551ff423.js",
  "vendor.js": "/js/vendor/vendor-bundle.d99dc0e4.js",
  "page1.css": "/css/demo/demo-bundle.795bbee4.css",
  "page1.js": "/js/demo/demo-bundle.e382801f.js",
}
后端的index.html
<!DOCTYPE html>
<html lang="en">

<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>demo</title>
  <link href="<%= manifest['page1.css']%>" rel="stylesheet">
</head>

<body>
  <h1>demo</h1>
  <script src="<%= manifest['page1.js'] %>"></script>
</body>
</html>
后端通过读取这个json文件，就可以动态渲染出文件的引用路径。
如果你曾经用过百度的打包工具FIS，它最后打包产出的map.json就是类似的资源文件列表。
使用这种方法还有一个好处：前面我们说过，如果文件上传至cdn，那么前端维护的html可能需要打包三次，因为不同环境的cdn地址不同。现在html交给后端维护了，那么这个问题就很好解决，前端只需要打包一次，不同环境的cdn地址可以让后端动态拼接生成。
当然，使用这种方法也会带来一个问题，这个json文件，后端怎么获取？
把这个json文件和其他静态资源一起打包上传到cdn上，后端服务器每次启动时，先到cdn上获取这个json文件，然后存到内存里
wget --tries=3 --quiet -O manifest.json http://static.demo.cn/demo/manifest.json?`date +%s` ## 防止缓存
方案的优点：简单方便，每次前端打包，manifest.json就会自动更新，上传到cdn同时覆盖前一个版本。 
方案的缺点：如果manifest.json更新了，后端则需要重启服务以便获取新的配置，当集群多的时候，重启耗费的代价可能很大。
2. 将manifest.json的内容放在配置中心里，后端则需要接入配置中心。每次CI打包后，调用配置中心更新接口，后端就能自动获取最新的配置。
在我平时工作项目中，这两种方案均有实现。
Node中间层
使用Nginx部署时，为了解决跨域问题，我们一般需要配置proxy_pass指向提供api的后端服务。
后端采用了SOA，微服务的架构时，proxy_pass指向的api服务器，其实本质也是一个转发服务。
前端ajax请求
// 获取商品列表
ajax.get('/api/queryProductList')

// 获取价格列表
ajax.get('/api/queryPriceList')
Nginx转发
location /api {
    proxy_pass https://demo.com; #后台转发地址
    proxy_set_header   X-Forwarded-Proto $scheme;
    proxy_set_header   X-Real-IP         $remote_addr;
}
接口转发到 https://demo.com/api/queryProductList 和 https://demo.com/api/queryPriceList
查询商品列表和查询价格列表其实是由两个不同的soa服务提供：
查询商品: product.soa.neko.com 
查询价格: price.soa.neko.com
因此，本质上https://demo.com这个服务也只是用来转发接口，同时对数据做部分的组装。那么这个服务，就可以用Node中间层来替代。使用了Node中间层，模板的渲染也可以从Nginx转移到Node了。
当然，多了一层Node，对于前端的综合要求也随之提高，后端的部署，监控，日志，性能等等问题也随之而来，全栈（干）工程师应运而生。
工作现状
我司大部分to C的前端项目，都是采用Node层渲染模板加转发接口的开发模式，还有少量项目采用Java tomcat渲染html模板。
大部分页面都是多页应用，并不是典型的单页应用。
Node层渲染模板，又分两种情况： 
需要支持SEO，则采用传统的模板渲染，填充展示数据。但是JS的业务代码，依旧前后端分离，并不在Node项目里。这类页面，一般都是采用Jquery+webpack模块化打包。 
 不需要支持SEO，则Node只渲染一个空html模板，页面内容完全由JS生成。这类页面，一般采用最新的前端MVC框架，比如Vue和React。
当然近几年比较流行的SSR方案，让Node渲染模板时可以直接使用Vue和React的同构组件，直出页面后，用户的交互体验又如单页应用般流畅，只能说：历史总是惊人的相似。
 从某种程度上说，SSR是一种向传统模式的回归，不过这种回归并不是倒退，而是一种螺旋式的发展。
实战
理论知识讲了那么多，现在我们来实战一下。在上一篇
深红：webpack多页面打包实践​zhuanlan.zhihu.com
里，我介绍了webpack多页打包的原理，同时搭建了一个简单的webpack4-boilerplate。这个模板只是一个前端开发模板，其实它还对应着一个node后端模板koa2-multipage-boilerplate。
这个node项目最重要的就是实现了前面说的：如何读取manifest.json文件，动态渲染静态文件的引用路径，从而前后端分离开发和部署。
详情见chunkmap.js这个koa2中间件的源码。
const chunkmap = require('./chunkmap');
app.use(chunkmap({
  staticServer: '//0.0.0.0:9001',
  staticResourceMappingPath: './mainfest.json'
}));
这个中间件接受两个参数 
staticServer：静态资源服务器地址，本地开发时，填写的就是webpack4-boilerplate这个前端项目启动的服务器。到了qa，产线时，则填写真正的cdn地址  
staticResourceMappingPath: 资源映射文件路径，也就是manifest.json文件
本地开发时的manifest.json，不带hash值
{
  "home.css": "/css/home/home-bundle.css",
  "home.js": "/js/home/home-bundle.js",
}
打包后的manifest.json，带hash值
{
  "home.css": "/css/home/home-bundle.d2378378.css",
  "home.js": "/js/home/home-bundle.cb49dfaf.js",
}
使用了这个中间件后，koa的ctx.state全局变量上就带有一个bundle属性，里面的内容是：
{
  "home.css": "//0.0.0.0:9001/css/home/home-bundle.d2378378.css",
  "home.js": "//0.0.0.0:9001/js/home/home-bundle.cb49dfaf.js",
}
然后通过模板引擎，动态渲染出实际页面。当然你也可以在页面中动态生成展示内容，从而支持SEO。
<!DOCTYPE html>
<html lang="zh-cn">
<head>
  <title><%= title %></title>
  <link href="<%= bundle['home.css']%>" rel="stylesheet">
</head>

<body>
  <div id="app"></div>
  <script src="<%= bundle['home.js']%>"></script>
</body>
</html>
总结
前后端分离带来了工作效率上的提高，Node中间层则给前端打开了一条走进后端的道路。当然机遇总是与挑战并存，在前端技术日新月异的今天，真想说一句：老子学不动了！
参考
大公司里怎样开发和部署前端代码？​www.zhihu.com

理解前后端分离开发

​ 前后端分离已成为互联网项目开发的业界标准使用方式，通过nginx+tomcat的方式（也可以中间加一个nodejs）有效的进行解耦，并且前后端分离会为以后的大型分布式架构、弹性计算架构、微服务架构、多端化服务（多种客户端，例如：浏览器，车载终端，安卓，IOS等等）打下坚实的基础。

以前老的方式是：

1.产品经理/领导/客户提出需求

2.UI做出设计图

3.前端工程师做html页面

4.后端工程师将html页面套成jsp页面（前后端强依赖，后端必须要等前端的html做好才能套jsp。如果html发生变更，就更痛了，开发效率低）

5.集成出现问题

6.前端返工

7.后端返工

8.二次集成

9.集成成功

10.交付

新的方式是：

1.产品经理/领导/客户提出需求

2.UI做出设计图

3.前后端约定接口&数据&参数

4.前后端并行开发（无强依赖，可前后端并行开发，如果需求变更，只要接口&参数不变，就不用两边都修改代码，开发效率高）

5.前后端集成

6.前端页面调整

7.集成成功

8.交付