| 
上周末，应邀在 Hacker News 上海聚会和 Ruby 上海活动上做了『风车』架构介绍的分享，在此感谢各位组织者和活动场地提供方。
风车这个项目开始于 2011 年 11 月份，之前叫做 Pragmatic.ly。从第一天开始我们基本上就定了大致的框架结构，在今天回头看，基本上整个架构都没有什么变化，可以算是个很成熟和很适合时代的方案。
最近一两年，作为技术人员，我们都能很明显的感觉到前端技术的飞速发展，比如 HTML5 支持，移动端优先、响应式界面设计以及层出不穷的各种客户端框架。而所有这些，都是基于一点：浏览器的高速发展。Chrome、Firefox、Safari、Opera
甚至于 IE，最近几年发展的都很快，不夸张的说，这些浏览器已经不再是浏览器，而是成为开放平台，有各自的扩展插件机制。这些极大地改变了网站开发的方式，网站开始应用化。
风车即是如此，设计得非常接近桌面应用，比如下面这些特点：
重客户端，所有的业务逻辑都在客户端，响应非常迅速
单页系统，项目内操作不需要刷新页面，操作非常流畅
三栏布局，左中右栏自左向右各司其职，信息非常清晰
实时更新，项目内任何更新都会实时的同步到你的页面
而在这个设计的背后，就是其本身的技术栈。
总览
Spine.JS
Rails
Pusher
风车在客户端使用的是 Spine.JS，后端使用的是 Ruby on Rails。实时消息同步用的是
Pusher。(三个里面有两个因为莫名其妙的原因打不开... -.-)
Spine.js 是一个轻量级的 MVC JavaScript 库，由《Javascript
Web Applications》的作者 Alex MacCaw 基于 Backbone.js 改良。Spine
库使用 CoffeeScript 编写，整体代码量仅一千行左右，比起 Angular.js, Ember.js
这些框架来说少的多，非常容易学习和上手。
Rails 目前我们在使用的还是 3.2 版本，基本上是用来做 API
服务器，只管数据，不做逻辑。上周活动有些朋友也问到基本只做 API 服务器，为啥不选用更轻量的方案如 Sinatra，Grape
之类。一是从开发上来说，Rails 默认这一套用起来比较舒服，我们除了 API 之外还有一些第三方应用的集成和管理性功能，所以整体建站更方便。二是我们目前还没遇到大的性能上问题，所以没必要去更换。如果下一阶段真有需要了，会把
RESTful API 专门独立出来。
Pusher 是一个基于 WebSocket 的实时消息推送服务，集成到应用中也非常方便。即使在不支持
WebSocket 的浏览器里（对，没错，说的就是 IE），也提供默认的备用方式，可选择 Flash Socket
或者 SockJS。整体体验来说，Pusher 算是一个很不错的解决方法，轻、快，给我们节省了大量开发时间，只需要关注产品的核心价值。不过如果你的应用对于实时性要求非常严格，比如交易系统，可能
Pusher 的稳定性还不够符合你要求，因为你懂的一些网络原因。
当浏览器刷新页面的时候，会向服务端发起一个请求。服务端收到这个请求后，会返回一个不带数据的纯
HTML 空模板。然后客户端渲染模板后，再次通过 RESTful API 向服务端请求项目的真实数据（JSON
格式），再由客户端对数据做处理并呈现，得到用户真正看到的页面。之后，会跟 Pusher 服务器建立一条
WebSocket 的长连接，接收推送信息。当服务端有任何更新的时候，会发送消息到 Pusher 服务器，再由
Pusher 服务器传输到客户端浏览器，页面同时也得到更新。以上，就是一个简单的过程。
|
