前后端协作之分离
前后端协作的三板斧，
前言
随着Web开发技术的更新换代，特别是Web2.0、NodeJS等平台或者概念的活跃，使得web开发越来越多样化，越来越灵活。最典型的一个特性就是，针对不同的业务场景，针对不同的需求、平台等内容，我们使用的技术栈会有所侧重，不再是以前的那种一杆枪打天下了。
从大的层面上来说，web开发可以分为面向浏览器的前端，以及面向服务端的后端。我个人一般习惯的将前端称之为浏览器端，主要是为了规避一些信息同步上的问题，因为对一些长期从事C、C++之类语言的底层开发的人员来说，除了底层，其他的都是前端。
web开发这个技术方向发展了这么久，依然摆脱不了下面这种原型，
简单来说，就是
- client端向server端发送request
- server处理来自client的请求，并返回response
原型非常简单，但是这仅仅是最基本的原理，其中有非常多的门道，实非一篇文章所能言尽。
耦合与分离
我刚毕业那会儿，大概6，7年之前吧，因为各种各样的原因，Java语言开始变得非常流行，当时在学校里基本上可以随处可见各种培训机构，广告吹得一个比一个厉害。那时候用Java来做web开发，基本上都是J2EE，一个人写servlet，同时也写jsp，最后往tomcat上一丢就完事了。
这种模型是典型的耦合式开发。所谓的耦合式开发有两个典型特点，一是同一种角色从前到后基本都写；二是基本上都是服务端模板、服务端渲染。
这种模式有如下几个非常明显的缺陷，
- 同一个角色干了多个事情，要经常切换思维场景，同是对开发者也提出了更高的要求。
- 不具备良好的拓展性和可维护性。
- 往往会将一些新思想和新技术拒之门外，难以尝试。
于是，人们便想出了一个法子，就是让面向浏览器的开发者和面向服务端的开发者分开。前后分离思想从此一发不可收拾，许许多多的前辈们在这条路上贡献了自己的思考以及解决方案。
我个人认为前后端分离的一个核心思想是：让合适的人做合适的事，并在此基础上持续探索在不同业务场景下的最优开发模式。
试想一下，假如现在我们要做一个项目，那么这个项目可能会有两个工程，一个前端工程，一个后端工程。需求确认完毕之后，前端开发者和后端开发者在一定的约定基础上并行开发，待开发完毕之后，再通过某一种方式进行集成即可。理想是美好的，但是现实却不会那么顺利，这中间有着许多的坑等着我们去踩。
在《Web开发模式的探索与思考》这篇文章中，我也有提到过，目前有两种主流的前后分离思路，一种是完全的前后分离模式，一种是中间层模式。这两种模式我个人觉得没有绝对的好与坏，两者都有各自切合的场景。
不过我看过很多的前后分离开发的网站，说实话体验不是很好。我个人感觉可能是网站的开发者走入了一个误区，
- 其一，在不合适SPA的场景下强拼硬凑SPA模式，使得前端过重。
- 其二，前后端之间的数据交换过度依赖ajax。在一些数据模块及交互复杂的页面上，使得ajax数据交互成为瓶颈。
- 其三，前端的技术栈是那种完全的前后分离模式，有点一条道走到黑的感觉。网站开发者们可能并没有考虑不同业务场景下对不同开发模式和技术栈的要求。
- 其四，可能是因为前端过重的原因，导致有一些非常明显的糟糕的操作体验，比如加载性能，视觉等待，白屏过长等等。
说实话，在两三年之前，我也是“完全前后分离”这一模式的铁杆粉，当时用AngularJS、ReactJS之类的MV*框架，觉得基本上没有什么事在前端范畴之内是解决不了，后端只要有ajax接口，只要给我前端提供数据就行了。我相信很多前端开发者现在依然有这种想法，而且可能还会觉得这么想是理所当然。
如果开发者把自己的眼界放远一点，不局限在前端这一范畴的话，你会发现除了前端这薄薄的一层之外，web开发中还有非常多的内容值得推敲的，只有站在更高的基点上，才能对整个web开发的生命周期做整体把握。
探讨
这里我先抛出一个问题，然后会在最后一篇文章中分析在两种主流的前后分离模式下如何做，以及它们的优劣势，最后会探讨一下应该怎么做。
问题是这样的，假设我需要做一个网站，这个网站会有类似企业首页那种偏资讯类的页面，然后会有用户体系。用户登录后，会有一个管理中心的中控系统，这个管理中心中会按照功能划分出好几个功能模块。管理中心的页面会给用户提供较多的交互操作。然后还有两个额外需求，一个是各个功能模块的页面之间会有数据传输；另一个是各个页面之间的跳转能够比较平滑，不要产生难以容忍的白屏。
更多建议：