概览

  1. 前后端分离不是一种技术，而是一种开发模式，一种架构模式；
  2. 通过Nginx、Apache、Tomcat等Web服务器进行有效解耦，前后端分离已成为互联网项目开发的标准方式之一；
  3. 前后端分离可以为以后的大型分布式架构、弹性计算架构、微服务架构、多端化服务（PC，H5，Android，IOS等）打下坚实的基础；
  4. 前端工程师一般情况下只需要关注页面的样式与动态数据的解析、渲染，后端工程师则更专注于具体业务逻辑的实现；
  5. 在开发阶段分离开发，部署阶段分离部署在不同服务器（同服务器不同目录）上，均算是严格意义上的前后端分离；
  6. storage/contract.jpgiag

优点

  1. 项目初期，项目参与者以需求分析、了解业务、撰写接口文档开始，减少了项目上线后部分人仍对项目整体逻辑不清晰的风险
  2. 开发初期使用mock实现前后端解耦，解决了前端开发重度依赖开发环境的问题，实现前后端并行开发
    • 提升开发效率，减少开发期间前后端之间的互相依赖
    • 增加代码的维护性&易读性，耦合在一起的前后端代码（SMARTY、BLADE模板），前端看不懂后端，后端看不懂前端
  3. 前后端职责分离
    • 前端倾向于呈现，着重处理用户体验相关的问题
    • 后端则倾处于业务逻辑、数据处理和持久化等
    • 在设计清晰的情况下（~~一般不清晰~~）,后端只需要以数据为中心对业务处理负责，并按约定为前端提供 API 接口
  4. 可以快速定位问题，减少出现互相甩锅的现象
    • 前端工程师负责页面逻辑，跳转错误，浏览器兼容性问题，脚本错误，页面样式等问题
    • 后端工程师负责接口数据出错，提交数据不成功，响应超时，返回敏感信息等问题
  5. 高并发情况下，可以同时水平扩展前后端服务器，达到支持高并发、高可用的目的
  6. 一定程度上减少后端服务器的并发|负载压力
    • 前端请求接口设置超时时间，如若接口超时（~~一般不超时~~）仍不能有效返回信息，则可仅显示前端页面（视页面逻辑而定），不至于出现白板页面
  7. 多端化服务可以可以让大量的组件代码得以复用
    • 以token认证为例，基于Oauth2的三种用户认证方式完全可以满足多端化服务
    • client认证（支持ios、android）、password认证（支持pc、h5）、personal认证（支持短信验证码登录）
  8. storage/ispsystem.pngmulti-end

缺点

  1. 前后端沟通成本提高（尤其是项目初期）
    • 前后端不分离时，前端主要关注用户体验、页面表现、加载速度、浏览器兼容性等，后端主要关注业务逻辑、高并发、高可用、高性能、数据存储安全等
    • 前后端分离后，均需要对业务逻辑进行足够了解，以便更好地对接口进行约定
  2. 接口设计主导权难以确认
    • 接口是前后端代码层面唯一的交流方式
    • 接口返回信息架构（{code msg data}）如何约定
    • 接口返回正确的方式有且只有一种，但错误会千奇百怪，较难约定
  3. 抛弃传统的Cookie、Session验证方式，转为Token验证，逻辑相对复杂
  4. 测试相对复杂，后端调试接口在页面没有调试完成前只能通过postman等外部工具进行调试，前端初期则只能依赖mock假数据