javascript - 为什么同步 SQL 是 "bad"？

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);
});

对于像这样的小 Action ，差异仍然可见，但看起来还不错。对于更复杂的查询，很容易发现自己陷入回调 hell 。

所以我的问题是:为什么 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​​ 应用程序服务器不同，在 ruby​​ 应用程序服务器中，单个进程一次只处理一个请求，node.js 进程可以轻松地将大量请求作为昂贵的 IO 操作(例如从磁盘读取) ，从数据库读取，与外部服务通信)do not block the process .

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

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

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

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

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

虽然异步/等待在 Node.js 中尚未正式可用，但它简化了异步代码 even further ，消除了像 co. 这样的图书馆的需要。使用类似 babel 的转译器这个功能可以用right now - 这就是我建议您考虑在类里面使用的内容。