为什么同步 SQL “不好”？

Question

我的学生在使用 ActiveRecord for Sinatra 和 Rails 时遇到了一些困难，但他们最终得到了它。

但是，他们在 Sequelize for Node 上完全耗尽了。

在我看来，Sequelize 和 AR 最大的区别在于 AR 是同步的，而 Sequelize 不是。

考虑：

# ActiveRecord
@post = Post.find(2)
render json: @post

---

// Sequelize
Post.findById(2).then(function(post){
  response.json(post);
});

对于像这样的小动作，差异仍然可见，但看起来并没有那么糟糕。对于更复杂的查询，很容易陷入回调地狱。

所以我的问题是：为什么 ActiveRecord 可以同步，但 JS ORM 不能同步？

我了解同步与异步的缺点。但同步性的缺点似乎并没有真正伤害 ActiveRecord。

Sequelize 的难点不仅仅是你要写一千遍.then(function(){})；理解回调是如何工作的也需要对 Javascript 有很大的了解，而且由于 Sequelize 是 Node 的主要关系 ORM，它使得 Node 对初学者来说不太容易上手。有人可能会说“初学者不应该使用 Node”，但 Rails 已经取得了巨大的成功，因为它努力让新手开发人员可以使用它。

Answer 1

同步的 JS ORM 不好，因为底层执行引擎 (Node.js) 是基于基于 execution model 的异步事件循环。

Node.js scales well 尽管是单线程的，唯一的原因是它使用非阻塞 IO 并且有一个 active ecosystem 库可以很好地与非阻塞异步模型配合使用。

正是因为如此，与 ruby​​ 应用服务器不同，单个进程一次只处理一个请求，node.js 进程可以轻松地处理大量请求作为昂贵的 IO 操作（如从磁盘读取，从数据库读取，与外部服务通信）do not block the process。

换句话说，如果 Node 是同步的，那么一个用户的数据库查询将导致服务器“挂起”并且在查询完成之前对所有其他用户无响应。

This post 详细阐述了 Node.js 事件循环的细节。

虽然这对于一直使用 javascript 处理回调的 Web 开发人员来说是直观的，但对于通常不熟悉面向回调的 API 的新开发人员来说确实很困难。然而，Node.js 的一些新进步让事情变得更简单了。

特别值得注意的是对生成器和 async/await 函数的支持。使用这些特性，我们可以消除回调金字塔，并使用正常的 try/catch 语法在异步代码中进行错误处理。

使用基于生成器的控制流库（如co），可以利用生成器（最新的 Node.js 版本已经支持）以线性方式编写异步代码。

虽然 async/await 尚未在 Node.js 中正式可用，但它简化了异步代码 even further，从而无需像 co.使用babel 之类的转译器可以使用right now 之类的功能 - 这是我建议您考虑在课堂上使用的功能。