由于本文篇幅较长，会分割成几个部分来讲解， 包括，前言&概述，多语言，缓存，部署，补充&总结 等 本文将不限于 sails.js 范围，会远远超出语言层面，上升并涉及到应用架构层面 有用之处则取之，无用之处则舍之，存疑之处则论之，有误之处则请指正之
前言
自14年入职 DJI 大疆创新 以来，官网的开发一直是Ruby，前后端结合紧密，后来虽然经过一轮前后端分离，但是，我们这些前端，也不得不兼职部分rubu开发。一开始都是拒绝的，后来还是干了，原因如下，1、箭在弦上不得不发，2、必须先要熟悉业务，3、感受一下ruby这门易用的语言。以前看过，松本行弘的《代码的未来》，其对编程语言的独特理解，确实令我想去实际的感受一下。搞笑的是，有两个前端哥们最后居然变成了ruby工程师，赤裸裸的背叛。
当然，这也非长久之计，前端的主要能力毕竟不是写ruby，一刚入职的华为的哥们，一听MD前端还要写ruby，搭了一天环境后，第二天，就提离职了。同学们都说，是因为我中午没请他吃饭，呵呵。
这中间的故事很长，不再细说...终于，15年的某天，我们决定要实现前后端彻底的分离了，后台不在使用ruby，一位百度来的前辈要使用php为基础，使用TMS系统生成静态页面，我是表示反对的，一旦这样搞，前端不是又要兼职搞点php，我还不如继续使用ruby呢。后面，经过，一段时间的实践和讨论，大部分还是觉得应当使用 nodeJS 来搞这个事情。降低，学习已及维护成本。
使用nodeJS，也不是说使用就可以使用， 如果，纯粹是前端来用这个东西，整个思维都是要进行极大调整，它更加偏向后端思维的。
1、项目本身是否符合node的特性？ node的基本特性是支持高并发，高IO，适用于，非密集运算项目。DJI官网，主要以展示为主，较少涉及数据存储，不涉及复杂计算。一旦，发布新品，我们面对的是数倍于平时的流量，同时，在高并发状态下，其主要瓶颈集中于静态文件及缓存读写。从这些特点来看，与node本身所具有的能力特性是十分匹配的。
2、是否具备相当的后端开发经验和能力？
DJI官网团队，当时，进行项目开发的6-7个人全部是前端，直到现在，仍然以前端为主。具备，后端开发经验的基本只有我，大学前3年基本把光阴耗在了.net的三层架构上。后来，写得有点烦了，再看发展态势，最终毕业选择了前端。当然，这种经验对这个项目来说无疑是有很大作用的。自然，后台，底层数据调用封装就是我的工作了。
3、是否具备服务器的运维经验？ 这个经验，有但是并不丰富，大学创业的时候，维护过自己的服务器。但是，这方面有ruby同事和运维的同事来补足，15年后半年，自己觉得长进最大的就是运维水平了。
概述
— 、备选框架 node 框架非常多，我们进过初步筛选后，选定了以下几个框架，进一步对比 Express, Koa,Locomotive,Hapi, Strongloop，Sails
这些框架的详细资料很容易搜到，这里为便于对比，只作简单介绍： 1、Express 是TJ的作品，一个灵活轻巧的框架，易于学习，生态丰富，使用广泛。在几年前，他几乎是node的首选框架。目前，作者本人已不再维护，交由strongloop公司维护，同时，随着其它强大框架的不断涌现，我们有了更丰富的选择。
2 、Sails，它是一个基于大名鼎鼎的Ruby中的Rails思想，建立起来的MVC框架，集成了express，soketIO,等流行框架，拥有完备的web应用结构，包括数据库，接口，路由，模板，安全，以及很好的实时交互特性（本项目中较少用到）。多数人，第一眼都会觉得，它是个牛逼的实时框架，但是，其实它的核心是一个强大而完备的WEB框架。
3、KOA，最大的特点是cool。本身极其轻小，支持同步风格的代码编写，有效的解决了，JS编程，尤其是node中长期存在的回调嵌套问题，深受广大劳动人民的喜爱。（在我们最新的项目中会使用到，后续会有文章介绍）
4、Strongloop公司也有自己的一套node框架，号称为企业级API框架，如果，是以数据服务为核心的应用可以考虑使用，从开发，部署，监控，它都拥有一套完善的服务体系，但是，应用尚不十分广泛，而且，这种一体化的东西，看上去开发简单，但其中的限制自然少不了的。
5、Locomotive, 是一个小巧但是强大的MVC框架，它基于express，支持restful。但有个致命的缺点，不论自身的，还是外部的能够找到的文档都非常少，解决问题，基本靠阅读源码。
6、Hapi，的基本理念是“配置优于编码”，不太喜欢这种编码风格，但是，这些约定，便于代码风格的统一，尤其适合多人合作的大型且复杂的项目。
在对比和试用了这些框架后，最终选择了sails，有几个原因，1，它是一个架构完善且功能强大的MVC框架，基本能涵盖我们项目中需要的东西。 2，github的人气很高，自身的文档还算可以，也有不少问答。express作为其Web的核心部分，遇到相关问题也好解决。3，历史原因，团队成员对Ruby Rails的编程风格比较熟悉，认可。
二 框架的选择 1、符合项目的实际需求 现有架构所面对的最大问题是什么？ 自己以及团队是否有足够的能力驾驭，有没有人使用过？ 产品的性质如何（内部使用，展示为主，或者存储为主）？ 需要或者可能面对的用户量级？
2、生态完善程度 在git上的排名如何，star多少？fork多少？ 是否在持续的更新？ 有多少公司在企业级的使用和实践，所选框架？ 文档是否完备，问答论坛有多少相关问答？ 能不能，通过阅读源码来解决，特定问题？
3、易用性，学习成本 与自己和团队现有的技术能力和结构，有合适的匹配度，降低学习成本 框架的架构清晰，封装得当 开发时，代码看上去，写起来都觉得自然而丝滑
4，完备程度与可扩展性 框架除了特点突出，是否对常见的功能模块有集成，或者预留接口？ 如果需要，对框架进行必要改造的成本如何？ 能否，比较容易的集成团队已有的功能及业务模块？
本章节，主要叙述一下前因，以及一些基本原则，下一节会开始实际内容的讲解： sails js 在 DJI 官网的应用（二）—— 多语言
DJI 官网团队持续招人中 ，欢迎NB的前端/全栈工程师们，加入我们一起奋斗，打造一流的技术团队， 来吧朋友，国内绝对一流的工资、福利，甚至期权，等你来拿，简历可发送至 fei.pan@dji.com
