收集一些关于前后端分离的资料，并做出一些总结，如有不正确之处请指出。
前言：
什么样的场景下，应该使用前后端分离
很简单。“不需要SEO的场景下，都应该使用前后端分离”。
所以在后台管理中，没有任何理由不使用前后端分离，代指SPA。
而在前台页面中，要认真考虑，不支持SEO的代价，不止几百万。
前后需要用户登录的页面，往往是不需要有SEO的，这里也可以拆解出来。
转自：https://www.zhihu.com/question/267014376/answer/444793972
什么导致的前后端分离：
实际上是先有了单页面应用，才会出现前后端分离。
单页面应用可以让用户不需要下载 APP，就可以拥有相似的体现。并且与早期的移动网页相比，拥有更好的体验，当页面加载完后，每打开一个新的链接时，不再需要等网络返回给我结果；我也能快速的回到上一个页面，像一个 APP 一样的体现这样的应用。整个过程里，我们只是不断地从后台去获取数据，不需要重复地请求页面——因为这些页面的模板已经存在本地了，我们所缺少的只是实时的数据
什么是前后端分离：
前后端之间使用 JSON 来交流，两个开发团队之间使用 API 作为契约进行交互。
即后台选用的技术栈不影响前台。当后台开发人员选择 Java 的时候，我可以不用 JSP 来编写前端页面，继续使用我的 React 又或者 Angular。而我使用 React 时，也不影响后台使用某一个框架。前后端分离和微服务一样，渐渐地影响了新的大型系统的架构。微服务和前后端分离要解决是类似的问题，解耦——可以解耦复杂的业务逻辑，解耦架构。可要是说相像吧，消息队伍和前后端便相似一些，通过传递数据的形式来解耦组件。
转自：你真的懂前后端分离吗？
前后端分离的助力：
前端mv时代：
1.浏览器提供可能性：
局部刷新： ajax
前端路由： hashchange/history
2.框架及工具支持：
框架：vue/react
前端路由 vue-router/react-router
前端数据存储: vuex/redux
3.中间层：Node.js
环境：前端开发者不需要本地起后端环境
联调：清晰的对接方式，JSON 实现前后端来说都是比较纯粹的
效益：可渐进式，前期可以将请求全部转发后端服务器，而后可以逐步将 Node.js 层作为用户的直接数据交换层
职责分明，后端服务化，Node.js 层处理接口用户相关的页面响应 及 数据交换
可组合性，后端服务化，Node.js 负责组合拼装，实现接口可复用率
4.前后端分工调整为：
前端：接收数据/返回数据，处理渲染逻辑
后端：提供数据，处理业务逻辑
转自：实践中的前后端分离
前后端分离的好处:
关注点分离 职责分离 对的人做对的事 更好的共建模式 快速的反应变化
淘宝前后端分离的实战历史：
情景：老子一個人全包了啊啊啊..（独自搞定哦，牛逼）
Roles: PM, DBA, RD, FED, Designer, ...
Skills: Linux, MySQL, JAVA, JavaScript, HTML, CSS, ...
Tools: phpmyadmin, photoshop, powerpoint, ...
结果：产品上线了→代码维护时候就难受呀。。。
于是乎：重构！为了更好的未来
下面来，WEB SERVER的架构改造：
后端MVC时代：
前端：那。。我呢？
这时的PM：前端你去套页面吧。（恩，完美的分工。。。）
到了互联网时代：根本顶不住了呀
没办法呀，前后端一起合作吧。。
好了，前端的代码出来了：
项目搞定了，可是前端的问题来了：
①前端代码越来越复杂
②无法统一协作模式，代码充满了约定
③JS跟CSS，依賴於後端產出的HTML
④有的数据來自AJAX，有的数据印在DOM上
⑤有的业务邏輯在前端，有的在Model层，更多的是在View层
好了，现在揭露本质：
①前后端依旧高度耦合
②前端依赖服务端开发环境
③在服务端View层高度耦合
④沟通成本高
⑤职责不清晰
VIEW层谁来維護？
①前端写Demo，后端套页面
后端需要写HTML
前端仍然确认后端写的HTML
②前端写View层，后端只管数据
前端需要熟悉后端语言
前端需要了解后端架构
可是还有问题呢：
① 无法良好的支持跨终端
②业务逻辑散落在应用中
③渲染逻辑强依赖后端页面
④只能用responsive design硬来
好吧，没什么好的办法，只能继续硬钢咯。。。。
高度耦合的前后端分工
① 沟通成本上升
②维护成本上升
③无法正确且快速的响应变化
④代码的腐烂只是迟早的问题
恩恩。。
第一次前後端分離大戰爆发
客户端mv时代出来了：
好了 ，分工吧。。。接口分離, 後端提供數據, 前端自己搞
MODEL层 - JavScript Object
VIEW层 - JavScript Template
业界满坑满谷的优秀方案
Backbone, EmberJS, KnockoutJS, AngularJS, React, etc.
好了，前后端职责清晰了：
后端：提供数据 处理业务逻辑 Server-side MVC架构
前端：接收数据，返回数据 处理渲染逻辑 Client-side MV* 架构 代码跑在浏览器上
分離乾淨了，分工明確了，但是：
各层职责重叠，并且各玩各的
Client-side Model 是 Server-side Model 的加工
Client-side View 跟 Server-side是 不同层次的东西
Client-side的Controller 跟 Sever-side的Controller 各搞各的
Client-side的Route 但是 Server-side 可能没有
性能问题
渲染，取值都在客户端进行，有性能的问题
需要等待资源到齐才能进行，会有短暂白屏与闪动
在移动设备低速网路的体验奇差无比
重用问题
模版无法重用，造成维护上的麻烦与不一致
逻辑无法重用，前端的校验后端仍须在做一次
路由无法重用，前端的路由在后端未必存在
跨终端问题
业务太靠前，导致不同端重复实现
逻辑太靠前，造成维护上的不易
SEO问题
渲染都在客户端，模版无法重用，SEO实现 麻烦
好了，再来，
第二次前后端分离大战爆发。。。
探讨：
重新定义前后端
传统认知的前后端
是依照 工作职责来划分的前后端
还是依照 硬体环境划分的前后端？
因為有了NODEJS
我们有机会从工作职责上
重新定义前后端的分层
重新定义的前后端
在服务器(JAVA) 与 浏览器(JS)的中间
架了一个中间层(NODEJS)
到底什么是node.js呢？？？？
前端熟悉的语言，學習成本低
都是JS，可以前后端复用
体质适合：事件驱动、非阻塞I/O
适合IO密集型业务
执行速度也不差
好了好了，开始职责划分：
实例展示：
淘宝首页优化
需求
静态资料展示，方便运营管理
更好的承载密集且庞大的流量
解决方案
页面缓存与定时刷新，返回缓存资料
NodeJS产出静态页面到CDN，定时刷新
淘宝详情页优化
需求
单日四亿PV，页面数据来自各个不同接口
为了不影响体验，先产生页面框架后
在发起多个异步请求取数据更新页面
这些多出来的请求带来的影响不小，尤其在无线端
解决方案
在NodeJS端使用 Bigpiper 技术
合并请求，降低负担
分批输出，不影响体验
接口性能优化
拆分大接口为独立小接口，并发请求
串行 => 并行，大幅缩短请求时间
部属优化
一台NodeJS对多台JAVA服务器
合理的分配服务器带来最大的产出
页面渲染优化
前后端共享模版 首屏服务器渲染
次屏浏览器渲染 局部刷新浏览器渲染
单页面应用优化
前后端共享路由与模版 前端换页，浏览器端渲染
直接输入网址，服务器渲染 SEO问题迎刃而解
可靠性优化
单元测试，页面测试，回归测试，持续集成
更多的可能
转自：淘宝前后端分离实战
注：以上内容均为方便个人学习所做的总结笔记，详情请看原链接，有好建议欢迎留言，后续继续补充。。
觉得好的资料：
③：前端发展史
④：前端发展历史
