Open johnnychq opened 6 years ago
前后端分离优劣的讨论很多，可以参见知乎Web 前后端分离的意义大吗？
我们今天回顾一下前后端分离的概念，展望下未来的发展
如果没有明确说明，这里的前后端分离指的都是人层面/工种上的前后端分离。
前端工种刚出现时，web研发模式非常老，没有前端模板的概念，html均以后端模板的方式放在服务端(jsp/php)。
web研发模式
js/css是前端的职责，但是服务端html(模板)是谁的职责却一直剪不断理还乱，不同的公司，不同的团队表现不一。html(模板)直接影响页面展现，所以认为是前端的范畴；但在源码管理和部署层面，又存在与服务端，且有一定的业务逻辑耦合，所以说是后端的范畴也不为过。
随着web研发模式的发展，前端模板的使用越来越广泛，尤其到mvvm时代，后端模板几近消亡，在技术上为前后端分离提供了基础。前后端分离的概念也就雨后春笋的冒出来了，基本上狭义的前后端分离可以理解为后端模板的消亡史。
上述前后端分离是主战场，主要技术推动，是最广为熟知和认可的前后端分离。除此之外，还有一个分战场，基于nodejs的前后端分离，推动的因素主要是前端整体能力的提升、个人空间的发展、对业务理解和话语权的把握上。
两个战场合在一起，构成了完整前后端分离的概念。在这个概念下，都需要前端研发人员和后端研发人员才能共同支持业务的研发诉求。
非前后端分离的时代，等同于服务端模板的时代。服务端模板因为耦合了展现逻辑和业务逻辑，导致无法明确职责，非常影响项目协同。很少团队明确约定，后端模板应该属于前端团队负责还是后端团队负责，具体项目协作中，这部分工作的划分也基本变成了一个艺术性的工作，非常考验项目经理的把控能力。
带来两个非常大的缺点, 因为前后端两拨人在同一载体上分别维护业务逻辑和展现逻辑，导致模板这一载体本身的逻辑说不清楚，时间久了，业务复杂了，维护性非常差。另外一个缺点是 ，职责不清导致的协同成本高昂，甚至出现踢皮球现象。
针对上述问题，后端的态度主要是甩锅，想避而不谈，很少提出解决方案；前端因为职业空间的缘故，毅然肩负起解决这个问题的责任。解决的思路分两派，一派是服务端模板客户端化，另外一派寻求服务端的解决方案。
关于服务端的解决方案，分为改良派和改革派，最后改革派存活下来了。改良派虽然失败了，但历史上的贡献不应该被抹去，简单分享下。
服务端的改良方案指在是在现有技术体系不变下，引入服务端mock/api层，使得前后端同学可以分别独立开发，其中服务端模板职责明确为前端所有。
改良派失败的原因是方案过于复杂，因为mock/api层需要完整模拟所有服务端模板的逻辑，而且这个过程与特别服务端语言/模板引擎耦合，很难推广和产品化；另外 ，前端开发时需要单独运行mock服务器；最后，腹背受敌，在纯粹的客户端分离和基于nodejs的前后端分离的夹击下，生存空间有限。
客户端模板化技术是随着RIA富Web应用的发展而发展，起初仅仅是局部采用客户端模板，后来整个页面都采用，最后把页面路由也搬到了客户端。整个网站变成了一个SPA单页面应用，展现逻辑写死在前端模板中，通过Restful接口获取业务数据实现业务逻辑的处理。
目前主流的React, Vue, Angular前端web框架均提供标准的SPA解决方案，MVVM成为标准的框架设计模式。
不过，SPA依旧依赖一个html容器，此容器必须存放在应用服务器端，不能像js/css/img一样托管在静态资源服务器/cdn上，原因主要是域名及访问路径问题，数据跨域访问也有影响。
关于html容器依赖问题，如果不解决，即把html作为空白模板放在服务端，我们称为传统的前后端分离；如果解决的话，把html也作为静态资源放在前端工程中，我们称为纯粹的前后端分离。
传统的前后端分离
纯粹的前后端分离
纯粹的前后端分离，可以让前端完全不依赖后端环境进行研发。但在部署的时候，需要将html与其他js/css/img资源分开打包部署，html部署在nginx中并做相应配置，js/css/img托管在静态资源服务器/cdn中。
另外，为了解决纯粹前后端分离SEO不友好的问题，践行了服务端同构渲染方案，这里就不赘述了。
基于nodejs的前后端分离，除了nodejs本身技术的成熟外，建立在几个背景下：
基于nodejs的前后端分离显然解决了服务端模板职责不清以及带来的相关问题，但同时走向了另外一个极端，把服务端路由、认证、权限、数据拼装和转换等web层的一系列工作都纳入到前端的范畴内。
但从技术架构来看，nodejs的引入不破坏后端本身技术架构体系，同时解决了服务端模板职责的问题，另外将web层统一交给前端，在多端复用、性能优化等场景也有了更大的发挥空间。但有个很大的非技术缺陷是，在时代背景下面，前端资源严重不足，将web层交给前端或许在项目协同及开发效率是有提升，但资源不足的先天劣势是很残酷的现实。另外，nodejs在技术上属于后端开发的范畴，对应的研发体系和配套措施成本也是需要考虑的。
前后端分离是具有中国特色和时代背景的，国外不存在所谓的前后端分离，国内的前后端分离更多的是时代背景下的产物。在中国互联网高速发展，对研发人员的大量需求与供给之间严重不足之间的矛盾背景下，只能通过降低对研发人员的要求，通过组织、协作、分工的手段来解决高水平研发人力资源不足问题。
随着程序员群体的成长，高水平人才的不断涌入，以及技术本身的发展及门槛的降低，web研发将会回到面向业务思考的全栈研发模式上，前后端分离的概念将会消亡，如果 有，也只会存在与特定场景。
基于人的/协作的前后端分离将会消亡，但基于技术的前后端分离将会永存。采用了nodejs的研发团队, html模板同样会放在浏览器端。技术的前后端分离是软件工程中分层思想的体现，不会因为人的缘故产生异同。
未来后端开发必定会有nodejs的一片战场，因为同种语言，相同模块管理，相似工程化手段的天然优势是其他语言难以望其项背的，而且这个战场不是在企业级应用，而是在消费者场景，快速迭代，快速试错，快速拿结果的场景。另外，企业级应用场景中的后端不能继续想着有前端帮你写页面，双方定义前后端接口了，学会运用企业级应用的前端解决方案，自己构建页面，快速响应业务才是核心。
最后，大浪淘沙后，时代背景的，人为的终将被淘汰；符合软件工程思想的，面向业务架构的终将留存。
前后端分离优劣的讨论很多，可以参见知乎Web 前后端分离的意义大吗？
我们今天回顾一下前后端分离的概念，展望下未来的发展
问题起源与两个战场
前端工种刚出现时，
web研发模式非常老，没有前端模板的概念，html均以后端模板的方式放在服务端(jsp/php)。js/css是前端的职责，但是服务端html(模板)是谁的职责却一直剪不断理还乱，不同的公司，不同的团队表现不一。html(模板)直接影响页面展现，所以认为是前端的范畴；但在源码管理和部署层面，又存在与服务端，且有一定的业务逻辑耦合，所以说是后端的范畴也不为过。
随着
web研发模式的发展，前端模板的使用越来越广泛，尤其到mvvm时代，后端模板几近消亡，在技术上为前后端分离提供了基础。前后端分离的概念也就雨后春笋的冒出来了，基本上狭义的前后端分离可以理解为后端模板的消亡史。上述前后端分离是主战场，主要技术推动，是最广为熟知和认可的前后端分离。除此之外，还有一个分战场，基于nodejs的前后端分离，推动的因素主要是前端整体能力的提升、个人空间的发展、对业务理解和话语权的把握上。
两个战场合在一起，构成了完整前后端分离的概念。在这个概念下，都需要前端研发人员和后端研发人员才能共同支持业务的研发诉求。
服务端模板时代
非前后端分离的时代，等同于服务端模板的时代。服务端模板因为耦合了展现逻辑和业务逻辑，导致无法明确职责，非常影响项目协同。很少团队明确约定，后端模板应该属于前端团队负责还是后端团队负责，具体项目协作中，这部分工作的划分也基本变成了一个艺术性的工作，非常考验项目经理的把控能力。
带来两个非常大的缺点, 因为前后端两拨人在同一载体上分别维护业务逻辑和展现逻辑，导致模板这一载体本身的逻辑说不清楚，时间久了，业务复杂了，维护性非常差。另外一个缺点是 ，职责不清导致的协同成本高昂，甚至出现踢皮球现象。
针对上述问题，后端的态度主要是甩锅，想避而不谈，很少提出解决方案；前端因为职业空间的缘故，毅然肩负起解决这个问题的责任。解决的思路分两派，一派是服务端模板客户端化，另外一派寻求服务端的解决方案。
关于服务端的解决方案，分为改良派和改革派，最后改革派存活下来了。改良派虽然失败了，但历史上的贡献不应该被抹去，简单分享下。
服务端的改良方案指在是在现有技术体系不变下，引入服务端mock/api层，使得前后端同学可以分别独立开发，其中服务端模板职责明确为前端所有。
改良派失败的原因是方案过于复杂，因为mock/api层需要完整模拟所有服务端模板的逻辑，而且这个过程与特别服务端语言/模板引擎耦合，很难推广和产品化；另外 ，前端开发时需要单独运行mock服务器；最后，腹背受敌，在纯粹的客户端分离和基于nodejs的前后端分离的夹击下，生存空间有限。
主战场 - 基于浏览器端的前后端分离
客户端模板化技术是随着RIA富Web应用的发展而发展，起初仅仅是局部采用客户端模板，后来整个页面都采用，最后把页面路由也搬到了客户端。整个网站变成了一个SPA单页面应用，展现逻辑写死在前端模板中，通过Restful接口获取业务数据实现业务逻辑的处理。
目前主流的React, Vue, Angular前端web框架均提供标准的SPA解决方案，MVVM成为标准的框架设计模式。
不过，SPA依旧依赖一个html容器，此容器必须存放在应用服务器端，不能像js/css/img一样托管在静态资源服务器/cdn上，原因主要是域名及访问路径问题，数据跨域访问也有影响。
关于html容器依赖问题，如果不解决，即把html作为空白模板放在服务端，我们称为
传统的前后端分离；如果解决的话，把html也作为静态资源放在前端工程中，我们称为纯粹的前后端分离。纯粹的前后端分离，可以让前端完全不依赖后端环境进行研发。但在部署的时候，需要将html与其他js/css/img资源分开打包部署，html部署在nginx中并做相应配置，js/css/img托管在静态资源服务器/cdn中。
另外，为了解决纯粹前后端分离SEO不友好的问题，践行了服务端同构渲染方案，这里就不赘述了。
分战场 - 基于nodejs的前后端分离
基于nodejs的前后端分离，除了nodejs本身技术的成熟外，建立在几个背景下：
基于nodejs的前后端分离显然解决了服务端模板职责不清以及带来的相关问题，但同时走向了另外一个极端，把服务端路由、认证、权限、数据拼装和转换等web层的一系列工作都纳入到前端的范畴内。
但从技术架构来看，nodejs的引入不破坏后端本身技术架构体系，同时解决了服务端模板职责的问题，另外将web层统一交给前端，在多端复用、性能优化等场景也有了更大的发挥空间。但有个很大的非技术缺陷是，在时代背景下面，前端资源严重不足，将web层交给前端或许在项目协同及开发效率是有提升，但资源不足的先天劣势是很残酷的现实。另外，nodejs在技术上属于后端开发的范畴，对应的研发体系和配套措施成本也是需要考虑的。
未来展望
前后端分离是具有中国特色和时代背景的，国外不存在所谓的前后端分离，国内的前后端分离更多的是时代背景下的产物。在中国互联网高速发展，对研发人员的大量需求与供给之间严重不足之间的矛盾背景下，只能通过降低对研发人员的要求，通过组织、协作、分工的手段来解决高水平研发人力资源不足问题。
随着程序员群体的成长，高水平人才的不断涌入，以及技术本身的发展及门槛的降低，web研发将会回到面向业务思考的全栈研发模式上，前后端分离的概念将会消亡，如果 有，也只会存在与特定场景。
基于人的/协作的前后端分离将会消亡，但基于技术的前后端分离将会永存。采用了nodejs的研发团队, html模板同样会放在浏览器端。技术的前后端分离是软件工程中分层思想的体现，不会因为人的缘故产生异同。
未来后端开发必定会有nodejs的一片战场，因为同种语言，相同模块管理，相似工程化手段的天然优势是其他语言难以望其项背的，而且这个战场不是在企业级应用，而是在消费者场景，快速迭代，快速试错，快速拿结果的场景。另外，企业级应用场景中的后端不能继续想着有前端帮你写页面，双方定义前后端接口了，学会运用企业级应用的前端解决方案，自己构建页面，快速响应业务才是核心。
最后，大浪淘沙后，时代背景的，人为的终将被淘汰；符合软件工程思想的，面向业务架构的终将留存。