传统的分离方法
在我的脑海中一提到前端和后端，基本上第一个出现的区别点就是:后端是跟数据库跟服务器打交道的，前端是跟浏览器打交道的。似乎没有什么问题，大家都这么认为的。
当然这没有什么错，我们一直以来都认为仅仅是以浏览器作分界，把这两部分的代码分离出来。但是前后端分离的初衷是为了分离前后端开发人员的职责，同时解决开发模式的问题。
但似乎他们的职责在以前甚至于现在都并不明确，虽然前端是跟浏览器打交道，但是最终浏览器拿到的页面是服务器通过模板生成的一个临时静态页面而已。所以，实际上后端也掺和进来了，因为他要处理模板。
当然，一般传统上的开发协作模式有两种：
-
一种是前端先写一个静态页面，写好后，让后端去套模板。静态页面可以本地开发，也无需考虑业务逻辑只需要实现View即可。不足是还需要后端套模板，这些前端代码后端需要浏览一遍，以免出错。
-
另一种协作模式是，前端直接去写模板，这样做的问题在于，前端编写过程中很依赖与后端环境，如果当后端没写完的情况下，前端几乎没法干活。
显然这两种方式似乎都有很多问题，但至少这还是目前为止大部分公司所采用的模式。他们从物理层来区分前后端的开发，同时淡化了前端在逻辑上的色彩。
由于前端所做的事情就是来实现一个页面的静态版本，所以，大多数公司又给前端工程师们找了点活干。你去看现在公司在招聘的时候前端工程师的要求，除了对页面的基本制作技能外还有额外的设计职责。
到这里原本我们以为已经将前后端分离开来了，但是在模版这个尴尬的问题上，前后端的工程师们绝对吃过不少苦头，因为在整体网站架构上，这并不是前后端的分离。
中途岛(Midway Framework)
简单的说，中途岛架构是基于NodeJs的，因为Js是一门前后端通吃的语言，它可以作为一个桥梁搭建在原始的前后端模式中。
前端来决定某个模板是服务端渲染还是客户端渲染，当首屏的时候，就在nodejs里面生成HTML，不是首屏的时候，就AJAX过来在浏览器端渲染展示。
加入NodeJs还有很多好处，比如NodeJs的高并发特性，请求合并等。同时使用nodeJs做桥梁，前端可以自己决定获取什么格式的数据。
SPA
现在有一个在前端领域很火的名词SPA(Single Page Application)也就是所谓的单页应用，在和用户交互的时候当用户点击某个物件或者按键的时候不会跳转到其他的页面，会像app一样在当前页面进行跳转，最典型的框架是：Angular、Backbone等。
开发移动商城就是采用Angular架构的一个SPA，切换页面或者场景的时候并不会跳转页面，只是去改变链接上的锚点，这个锚点由ui-route监听到，从而就由前端实现了对URL的掌控。SPA无需任何模板来控制输出，
它的展现完全靠JavaScript控制，数据是SpringMVC通过restful的api接口提供的，所以SPA所采用的前后端的分离，已经基本分的很清楚了，后台只管数据输出和业务逻辑处理，前端负责交互逻辑和界面展示。
这样就需要前后端在接口的方面约定好，以避免不必要的麻烦。Blueprint是一个用来编写Api文档的工具包，对restful API几乎是完美兼容。
一、什么是前后端分离？
前后端分离的例子就是SPA(Single-page application)，所有用到的展现数据都是后端通过异步接口(AJAX/JSONP)的方式提供的，前端只管展现。
从某种意义上来说，SPA确实做到了前后端分离，但这种方式存在两个问题：
- WEB服务中，SPA类占的比例很少。很多场景下还有同步/同步+异步混合的模式，SPA不能作为一种通用的解决方案。
- 现阶段的SPA开发模式，接口通常是按照展现逻辑来提供的，有时候为了提高效率，后端会帮我们处理一些展现逻辑，这就意味着后端还是涉足了View层的工作，不是真正的前后端分离。
SPA式的前后端分离，是从物理层做区分（认为只要是客户端的就是前端，服务器端的就是后端），这种分法已经无法满足我们前后端分离的需求，我们认为从职责上划分才能满足目前我们的使用场景：
- 前端：负责View和Controller层。
- 后端：只负责Model层，业务处理/数据等。
二、为什么要前后端分离？
2.1 现有开发模式的适用场景
- 比如后端为主的MVC，做一些同步展现的业务效率很高，但是遇到同步异步结合的页面，与后端开发沟通起来就会比较麻烦。
- Ajax为主SPA型开发模式，比较适合开发APP类型的场景，但是只适合做APP，因为SEO等问题不好解决，对于很多类型的系统，这种开发方式也过重。
2.2 前后端职责不清
在业务逻辑复杂的系统里，我们最怕维护前后端混杂在一起的代码，因为没有约束，M-V-C每一层都可能出现别的层的代码，日积月累，完全没有维护性可言。
虽然前后端分离没办法完全解决这种问题，但是可以大大缓解。因为从物理层次上保证了你不可能这么做。
2.3 开发效率问题
淘宝的Web基本上都是基于MVC框架webx，架构决定了前端只能依赖后端。
所以我们的开发模式依然是，前端写好静态demo，后端翻译成VM模版
直接基于后端环境开发也很痛苦，配置安装使用都很麻烦。为了解决这个问题发明了各种工具，比如VMarket，但是前端还是要写VM，而且依赖后端数据，效率依然不高。
另外，后端也没法摆脱对展现的强关注，从而专心于业务逻辑层的开发。
2.4 对前端发挥的局限
性能优化如果只在前端做空间非常有限，于是我们经常需要后端合作才能碰撞出火花，但由于后端框架限制，我们很难使用Comet、Bigpipe等技术方案来优化性能。
三、怎么做前后端分离？
- 前端：负责View和Controller层。
- 后端：负责Model层，业务处理/数据等。
试想一下，如果前端掌握了Controller，我们可以做url design，我们可以根据场景决定在服务端同步渲染，还是根据view层数据输出json数据，我们还可以根据表现层需求很容易的做Bigpipe,Comet,Socket等等，完全是需求决定使用方式。
