Sails 0.8.9: 深受 Rails 启发的实时 Node MVC 框架

Sails 是一个构建于 Node.js 之上的实时 MVC 框架。得克萨斯州奥斯汀的 Balderdash 团队在 4 月 9 日发布了 Sails 0.8.9 版。Balderdash 团队长期并持续地致力于为现代 web 应用打造类 Rails 的开发平台。

在 Rails 诞生已逾 8 年之际，Balderdash 团队将基于 MIT 许可的 Sails 框架展望为向前进化过程中的重要一步：它汇集了 Rails 传承的在实时 web 新型能力方面丰富的开发者经验。

InfoQ 联系到了 Sails 框架的作者 Mike McNeil ，并对这个发展势头迅猛的框架进行了更深入地剖析。

INFOQ: Sails.js相比于其他的Node.js实时框架有何不同？( Meteor、 Derby和 SocketStream)****？

Mike: Sails.js 从一开始就是为让我们的企业和初级用户能够更有效地创建强大、稳定的 Node.js 应用而生的。总的来说，我们采用了那些大伙曾经使用过并且值得大家信赖的工具，并以可复用的方式提炼出最佳实践。举个实际的例子，我们重度地依赖两个由 LearnBoost 公司成员开发的框架： Socket.io 用于服务器推送，而 Express 则用于我们的 web 路由和模板。Express 是最流行的 Node.js 框架（至少 13,000% 的流行，但是谁又在乎这些呢？）。我们在处理每件事的时候都避免重复发明轮子。

但这并不是说我们没有推动我们自己的组件发展——我已经完成了一个 ORM 组件的构建，这可能是 Sails 源代码中最大的一个组成部分，并且也拥有最多的测试代码。我们在 WebSocket 代码的处理上采用了截然不同的方式：在处理实时消息传递的时候我们并没有选择维护独立的代码基础，你可以使用同样的代码来处理你的常规 API。这意味着，不论你的应用需要针对 WebSocket 还是 HTTP 进行构建，项目中都将充满你习以为常的良好的 ole Express 代码。

直到我开始 Balderdash 团队的项目，我才发现这个决定是多么的重要。我们能够在不到一个月的时间内构建一个旨在支持超过 300,000 用户的、 API 驱动的、实时的后端。它借鉴了 Box.net API，但是同样可以实现将所有的文件更新进行实时广播。

INFOQ: 鉴于Meteor目前在该领域风头正盛，你能特别针对它和Sails之间的异同做一些介绍吗？

Mike: 首先，我们可没有 1200 万美元（译者注：应用开发框架开发商 Meteor 宣布在 A 轮融资中获得了来自 Andreessen Horowitz 领衔投资的 1120 万美元）。但是说真的，我们解决的是不同的问题：Meteor 专注于创建一个完全新型的实时 web 应用框架。而 Sails.js 则是一个通过使用开发者们耳熟能详的 MVC 范例，为各种类型的应用创建实时 API 的专注于解决方案的工具。

早在我们洽谈第一笔企业生意的时候，我就意识到要创造一个全栈框架（full stack framework）是非常艰巨的，更不用说市场上已经存在像 Meteor 这样被大众所接受的框架。Node.js 是一种被证明了的技术，但是很难说服客户能够做出改变来实施全栈的 Node.js，更不用说尝试着让他们在前端采用新的 web 框架。

最终，人们都会基于当前工作所属项目中的需求来选择适合他们的框架——毕竟，这是开源的。

INFOQ: Sails.js**** 是如何处理负载均衡及其规模伸缩的？

Mike: 无论你的部署位于企业防火墙内的数据中心，还是处于虚拟化的环境，又或者是直接工作于像 Joyent 这样的云供应商，甚至是托管在 Modulus 或 Nodejitsu 这些 PaaS 上，Sails 的部署策略与其他类型的 Node.js 应用的方式是一样的。我知道有一些开发者，他们在网络交流中对 Nodejitsu 针对 Sails 应用的安装支持赞不绝口，这可能是一种非常好的方式。你会希望遵守那些相同的标准并继续遵守在 Express 或 Socket.io 应用中被测试过的那些最佳实践。我们固有地支持将 Redis 作为会话以及发布订阅或套接字的存储。这意味着你将可以根据你的需要创建多个 Sails 服务器的副本，而一切将可以继续正常工作。

Sails 让你可以更容易地将会话和套接字存储到 Redis 之中。至于你的数据模型，你会希望相应地对数据库进行伸缩。你将可以复用在任何其他应用中你曾经面临过的伸缩性考虑。

INFOQ: angular.js 或 ember.js 以及其他客户端企业框架有没有打算与 Sails.js 进行更好的协作？又或者 Sails.js 会不会强制应用采用自己的结构？Sails.js有没有打算与移动设备协同工作？

Mike: Sails 背后的基本设计哲学之一就是设备不可知论（ device agnosticism ）。我们不想去预测或约束你如何构建你的前端。这意味着无论是向一个浏览器、还是向一个原生移动应用或是向一个腕表甚至是冰箱，我们都希望可以足够灵活地按你需要的方式来传递数据。

这是一种被普遍接受的方法，特别是在企业中，你可能会听到它被称为 SOA （或者是面向服务架构）。大多数的公司都热衷于构建 SOA。这是为什么呢？嗯，让我们这么说吧——访问互联网的设备的种类数量在以后只会有增无减。

Sails 对于在如何构建你的前端方面给予了零控制，而与此不同的是它为你使用诸如编译 LESS 和 CoffeeScript 等提供了一些可选工具——如果你正在处理这些事情的话。我们在原生的 PhoneGap 应用和 Chrome 扩展程序中使用 Sails，其他的一些开发者正在使用 Sails 来为他们的 Backbone 、 Ember 、 Angular 、 ExtJS 、 原生 iOS 和原生安卓应用提供强大的后端。我们有两个贡献者对 Sails 的使用有着更酷的方式： Dennis Bartlett 正在构建一个具有平视显示器（HUD）的自行车头盔，而 Thom Simmons 使用 Sails 为他的智能飞盘提供 API 服务。

INFOQ: “免费”在每个集合中使用JSON api能带来什么优势？

Mike: Sails blueprint 是我们最初为原型设计添加的一项功能，但事实上这一功能最终在生产中为我们增添了丰富的价值。如果你拥有了可测试、可搜索、可排序、可查询这样看上去如此性感的 API，那么你为什么不使用它呢？你可以通过混合使用 blueprint API 来做一些真正有趣的事情，尤其是当你在更换模型适配器的时候。它能够很整洁的在一个 LDAP 数据库（LDAPAdapter）上创建可查询的 API，或者不编写任何代码就可以对 tweet 消息 (TwitterAdapter) 进行搜索。

对于“编写你自己的模型适配器”来说，我们是极其友好的（你将会注意到 Sails 项目实际上伴生了一个适配器目录，该目录中打包了应用特定的适配器）。这样做的目标是尽可能多的在 ORM 中保持 API 集成——它催生了更加整洁、规范的代码，当你们的开发人数在不止一个人的情况下这是非常赞的。还有一个非常不错的优势就是你可以在你的 API 中使用来自适配器的真实数据。

INFOQ: Sails.js**** 有“迁移（migrations）”的概念吗？

Mike: Sails 支持将模型挂钩（hooking）到无模式数据库和“模式”数据库。很明显。当使用像 Mongo 或 CouchBase 这样的数据库时，并不真正需要迁移，但是针对更加结构化的数据模型，Sails 将会发挥起它的作用。在每个适配器基础之上，你可以控制在服务器启动时发生的一切。

我并非 Java 的狂热者，但是我必须承认 Hibernate 的自动迁移是相当了不起的。如果你是一个 Java 开发者，你可能会认出这个迁移装置，这是我们对 Hibernate 和 Grails 的 “dbCreate”这一了不起的概念的实现版本。我原本就是 Grails 背景的程序员，所以这源自于我的灵感。当我审视 Rails 的时候，我对手动进行数据迁移的必要性感到非常吃惊。我可以理解在数据处理上的进行如此的设计，但是在处理模式方面却无法理解。不过我揣摩着如果你这样想就会觉得这是理所当然的——Rails 是差不多 10 年前首次登上竞技舞台的，而这些年已经发生了如此翻天覆地的变化。

我们在这方面尝试了很多不同的概念。程序员并没有什么技术理由需要去关注在基于模式数据库中的迁移。我们拥有足够的信息来实时处理好这些事情。无论如何，目前已经具备便利的配置装置来提升开发过程中的效率，比如在服务器重启时删除掉数据库表格。我们倾听来自社区的声音，并且在如何提升效率而不增添非必要任务的进行迁移方面紧跟时代的步伐。

INFOQ: Sails.js**** 的下一步会怎么走？你对该项目在明年的发展是如何看待的？

Mike: 总之，社区的的力量真的非常惊人，而我将会致力于确保 Sails 项目继续存在，并且是一个能为实际应用案例的真实使用提供支持的项目。在我发布首个屏幕录像的两天之后， Ted Kulp 和 Carlo de Celico 就为 Sails 构建好了 Mongo 和 Redis 适配器。根据目前我们所看到的，如果继续发展下去，我认为我们将会看到更加大量的社区贡献，这些社区贡献将会主要围绕在增加不同的模型适配器和模板视图引擎这两个方面。

到目前为止，我们的功能都是由那些为了真正赚取美金的真实应用所驱动的，并且我也认为这种方式在短期内不会发生变化。举个例子，现在我们有一个需要将会话存储到 CouchBase 的客户端，所以我们就会增加将会话存储挂钩到任意的 Sails 适配器的能力。

我认为在 Sails 中仍然缺失的最大部分，并且不是由客户端需求直接驱动的功能是对模型中校验和关联的原生支持。比如像 Express 和 Socket.io，你可以自行强制此类的约束，但是到目前为止，Sails 还没有好的工具来实现。在今年的早些时候，我创建了 anchor 作为数据校验和键入工具来帮助你以一致的方式处理好数据校验。下一步就是将它集成进 Sails，我们将会在这个春季和初夏进行这项工作。

再来点神秘感吧，我对增加更多的可选 blueprint 功能有一个全面的计划，但是现在还对大家保密。:)

英文原文链接： Sails 0.8.9: A Rails-Inspired Real-Time Node MVC Framework