经常我们需要一个非常轻量级的框架，来满足我们很多非常简单的需求，同时又要求一定的扩展性、灵活性和松散性，要求快速开发，又有一定的承载能力，这里设计了一种简单的解决方案。
数据服务框架 >> Github
结构
|----------------------------------------|
| web/HTML5 | mobile | ect. |
-----------------------------------------|
| React/Flux/React Native | ^ |
-----------------------------------------|
| rest api/node/express | socket.io |
| -----------------------------|
| | database/redis/storage |
|----------------------------------------|
为了更明晰的分层，这里分为多个服务，因为都是基于nodejs，所以要整合在一起也是非常简单。
- Rest Api，提供基础数据服务，采用http协议，由node/express组成。
- socket，提供长连接服务，采用socket.io，可以直接连接数据层，也可以通过http协议连接数据层。
- 表现层，React作为基础页面构建方法，结合原生方法，来构建具体应用，或者应用的一部分。
数据层
这里我选择MySql作为基础数据存储格式，redis作为缓存。
大部分时候我们还是需要传统的关系型数据结构，MySql是最佳的选择，同时PostgreSQL, MariaDB也是一种选择。
作为NoSql的其中之一，mongoDB，也是非常热门，但是由于资源占用太高，不太适合小型项目。
Node
为什么会选择node作为基础语言来构建整个框架呢？首先让我们比较比较其他几种语言。
JAVA / Spring
现在最火热的spring架构，几乎所有大型企业的首选框架。优点多的不用说明了，但是作为我们需要快速开发以及快速上手的框架并不友好，有太多的坑，而且JAVA作为一门强类型的语言，太过于繁琐。分层明确(Model, DAO, Service, Controller)的同时，也降低了开发速度。
另外一个让我放弃Spring的原因在于资源占用太高，JAVA的运行环境就需要非常大的内存，如果你的开发机器上需要运行MySql, redis, IDE, tomcat等等，还是有一点压力的。
Python / django
也是一个比较热门的开发框架，也有挺多的成熟应用，算是一个Ruby On Rail的Python版本。但是毕竟Python并不是专门为服务器开发出来的语言，而且和C语言有着一些联系，所以感觉并不太适合现在的时代，目前开源社区的支持也在逐渐下降。
django自己有一套ORM的系统，但是并不够灵活。
我比较喜欢的是Python的修饰方法，可以非常灵活的配置一些方法的过滤器。(听说ES7里也要有统一的特性？)
PHP
感觉PHP是专门为了WEB而设计的语言，虽然有一些像think php这样mvc的框架，但是感觉作为一个中间层还是不太稳定。
Node.js
Node是一个处理IO密集型业务非常好的选择，通常我们的中间层不会有大量的计算，多数为读取写入数据，其他的框架都是选择等待事务完成，而且每个请求会生成一个进程，导致一台机器的并发数直接由内存决定，Node在这方面可以使用更少的资源来获得同样的效果。
Node目前非常的火爆，开源社区也非常活跃，很多应用或框架都已经在node上面开发，而且开源模块非常完善，npm也非常好用。比如我在上层采用的React。
同时Javascript作为一门前端语言，简单易学，可以有很多前端开发人员进入。
在公布了ES6以后，Javascript感觉已经摆脱了脚本语言这一不太好的特性，更像一门专业面向对象语言。不过可惜的是，到目前为止，虽然v8已经基本支持了所有ES6特性，但是最新的node v6并没有完全支持，加上--harmony也只能支持一小部分，目前我们还需要借助第三方库。
只能说，感谢v8!
同时，可以看出这个框架的大部分都是由js来组成，所以选择Node来作为中间层的开发也是很理所应当的。
下一步
整个中间层的构建。请见下一篇。
后记
关于Node服务的效率问题，虽然官方说明以及很多自来水的吹捧，感觉非常的优秀，但是实际项目中还是需要根据实际情况来做判断。
不过如果遇到了效率问题，Node还是可以很方便的和其他语言混编的，找出最消耗时间的地方，用C/C++改写也是非常快速的。
稳定性是Node比较弱的一个方面。一个线程容易因为一个小错误而使整个服务崩溃，所以除了需要更仔细的错误处理，还需要均衡与热备来确保服务质量。
由于Node的异步语法会导致更多的嵌套关系，使用泛滥会导致代码难以理解，所以需要统一整个项目的规范与习惯。（比如使用Promise代替callback函数）