探究 ：深入聊聊前后分离架构前后分离，一直是一个相当泛泛的问题，前后分离到底好不好？没有绝对的对，没有绝对的错，业界就这个问题已经激烈的探讨几年了.出现讨论的点在于：分离当然是好的,但是以什么样的服务需要进行前后拆分？拆分到什么粒度？前后端如何配合？

截图时间: 2018-08-30 - Github

我们随意在 Github 输入前后分离关键字，看下搜索的结果: 1K 的库 11k 的 Issues 足以说明前后分离的趋势，可以想象激烈程度，业界比较有名的讨论：Web 前后端分离的意义大吗？，值得一提的是：前排对于这个问题讨论比较深刻的大部分都是全栈工程师。因为全栈对全局的了解相对比单纯做前端、后端全局观念更强一些，考虑的问题更多一些。
筛简历引发的思考和分析后端职位的怪圈在公司的简历库随手截几个局部的图，近两年面试过很多的 1-3 年 java 开发者，在筛选简历和面试过程中，也发现了几个问题：相当多一部分 javaer 技术栈上总是多了那么个 HTML ajax jquery bootstrap easyUi ，看起来很唐突，如果面试提到了前端技术栈，基本没有能答的很好的，甚至有的人连 原型链 都不知道。这也是大部分人对全栈的误解，其实我是不太感冒这样的简历的，因为没有什么亮点，技术栈不是写的越多越好，总结起来：他们对前端的掌握很基础，勉强能胜任一些业务上的工作。那为什么这么多人都掌握一些前端技术呢？我分析可能有三点：
思考原因：

• 培训机构的兴起，机械化的教学
  
• 求职者自身的兴趣
  
• 一些公司的技术栈不全，对技术没有追求，大部分用的几年前的架构，前后业务耦合很大，市场缺口大
  
  

分析因为我也维护过几个月的敏感项目，深有体会，只写服务端的人是无法胜任这项工作的，如果多数的 开发者 这样的简历，可以推测：现在的 IT 行业中前后端糅杂一起的架构还是存在、并且有一个量级，这导致他们不得不寻找一些懂得一点前端技术的人来开发项目，减少沟通的成本，加快项目的进度，这也就催生了很多所谓的 web 开发培训机构。

你问我当年维护的开心吗？一会告诉你。

什么是前后分离前后端分离并不是什么新鲜事，到处都是前后端分离的实践。然而一些历史项目在从一体化 Web 设计转向前后端分离的架构时，不可避免的会遇到各种各样的问题。由于层出不穷的问题，甚至会有团队质疑，一体化好好的，为什么要搞前后端分离？说到底，还是技术和思维方式没转变过来。
一体化模式其实在上一开篇：纵观历史演变 中已经提到过了，不在赘述。
前后分离看起来应该是这样的：


前后分离就是在架构层次上 构建项目或对现有的项目 客户端 服务端 分离开，减少前后端代码的耦合度，大家一致认同的前后端分离的例子就是***SPA(Single-page application)*** ，所有用到的展现数据都是后端通过 JSON 但不仅限于 JSON 的方式提供的，前端只管展现,提供更好更绚的交互，后端只管提供更健壮的高可用服务。
千万不要有先写项目，写完再重构的想法，项目初期能一步到位最好，何必再去重构，然后不得已抛弃一些已经写完的组件、库浪费人力呢？
前后分离解决了什么问题每个人各尽其职好的开发者是可与不可求的，若寻找一个 优秀的 full_stack 更是难，从校招进行培养也不太实际，招一个能力一般的程序员，技术驱动性比较差，甚至拖慢产品迭代。分离开来我们就可以专注于 前端、 服务端 领域去寻找专业的人才。
解耦前端后端代码大量耦合代码看起来是这样的：


看看简单例子吧：
//(node端处理)if (is_weixin()) {init(['api','image','xxx','...',], function () {<%- doSomeGloble %>});} else {}//接收node端一些数据let blogs = <%- blogs %>;let users = <%- users %>;                     复制代码这还不是 JAVA 模板 而是相对轻量、优雅的 NODE 的 EJS 渲染的，这还好，我见过更令人难受的代码，经常为了一个问题要回头看 N 多代码，这里就不写了。
那么前后分离如何让它们解耦变得更清晰？后面会结合服务端统一补充。
什么项目不适合前后分离blog、文档你说你搭建一个博客、 API 文档系统 这种小项目，一个人就可以开发。搞了一个前后分离，需要分离部署。又增加了 SEO 的复杂度，增加了开发的周期、增加了用户部署的难度，何必呢？当然，如果只是技术实践的一种学习方式，还是欢迎的。
前后分离带来的问题，如何解决？沟通成本问题

前端妹子：哥，获取全部博客调哪个接口？

哦，昨天不是发你文件了吗

前端妹子：我找不到了

奈斯