node.js - Koa/Co/Bluebird 或 Q/Generators/Promises/Thunks 相互作用？ ( Node .js)

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

7年前关闭。




Improve this question




我正在研究部分使用 Koa 构建 Web 应用程序，但我不太了解如何、何时以及为什么在支持性的“使异步更容易”技术/方法之间进行选择和应用的范围(下面列出)。

总的来说，关于这个主题的网络上不同的指导仍然使事情变得模糊，特别是关于不断发展的最佳实践，或者至少是更好的实践，以及在什么情况下。网络上似乎很少或没有将其全部放在上下文中的内容。

我希望对这个大屁股庞大帖子的回应可以纠正这一点。也许下面的问题可以激励某人写一篇详尽的博客文章或类似的文章来解决这个问题。我的感觉是，我什至不是唯一一个会从中受益的人。

因此，如果聪明的社区可以帮助回答并澄清与下面列出的技术有关的以下问题(以粗体显示)，我会很高兴:

-- a) How, and under what circumstance (as applicable) are they complements, supplements, substitutes, and/or overlapping solutions to one another?

-- b) What are their trade-offs in respect to speed-performance, error handling ease, and debugging ease?

-- c) When, where, and why may it be better to use "this" versus "that" technology, technologies-combo, and/or approach?

-- d) Which technologies or approaches, if any, may be "dimming stars".

(希望作为答案一部分的意见可以得到很好的解释。)

==============================

技术:

* Koa *

我的理解:

Koa is a minimal foundation for build Node apps geared for taking advantage of ECMAScript-6 features, one feature in particular being generators.

* 合作 *

我的理解:

-- Co is a library of utilites for running ECMAScript-6 generators (which are native to Node .011 harmony), with the goal to allieve some/much(?) of the need to write boilerplate code for running and managing generators.

-- Co is intrinsically part of Koa(?).

具体问题:

-- If and how does one use Co differently in Koa than in a non-Koa context. In other words, does Koa wholly facade Co?

-- Could Co be replaced in Koa with some other like generator library if there is/was a better one? Are there any?

* Promise 库，例如“Q”和 Bluebird *

我的理解:

-- They are in a sense "polyfills" for implmententing the Promises/A+ spec, if and until Node natively runs that spec.
-- They have some further non-spec convenience utilities for facilitating the use promises, such as Bluebird's promisfyAll utility.

具体问题:

-- My understanding is the ECMAScript-6 spec does/will largely reflect the Promises/A+ spec, but even so, Node 0.11v harmony does not natively implement Promises. (Is this correct?) However when it does, will technologies such as Q and Bluebird be on their way out?

-- I've read something to the effect that "Q" and Bluebird support generators. What does this mean? Does it mean in part that, for example, they to some degree provided the same utility as Co, and if so to what degree?

* 重击和 promise *

I think I have an fair handle on what they are, but hoping someone can provide a succinct and clear "elevator pitch" definition on what each is, and of course, as asked above, to explain when to use one versus the other -- in a Koa context and not in it.

具体问题:

-- Pro and cons to using something like Bluebird's promisfy, versus say using Thunkify (github com/visionmedia/node-thunkify)?

==============================

为了给这篇文章及其问题提供一些进一步的背景，如果可以讨论和对比以下网页中介绍的 Koa 技术(特别是在优缺点的基础上)可能会很有趣:

-- a) www.marcusoft . net/2014/03/koaintro.html (Where's the thunks or promises, or am I not seeing something?)

-- b) strongloop . com/strongblog/node-js-express-introduction-koa-js-zone (Again, where's the thunks or promises?)

-- c) github . com/koajs/koa/blob/master/docs/guide.md (What does the "next" argument equate to, and what set it and where?)

-- d) blog.peterdecroos . com/blog/2014/01/22/javascript-generators-first-impressions (Not in a Koa context, but presents the use of Co with a promise library (Bluebird), so I'm assuming the technique/pattern presented here lends itself to usage in Koa(?). If so, then how well?

谢谢大家!

Answer 1

一个月以来，我一直在广泛地使用发电机，所以也许我可以尝试一下。我会尽量减少意见。希望它有助于澄清一些困惑。

缺乏最佳实践和更好解释的部分原因是该功能在 javascript 中仍然很新。仍然很少有地方可以使用生成器 node.js 和 firefox 是最突出的，尽管 firefox 有点偏离标准。

我想指出，有像 traceur 和 regenerator 这样的工具可以让你使用它们进行开发，并允许你将它们变成半等效的 ES5，所以如果你发现使用它们很愉快，那么没有理由不开始使用它们，除非您的目标是过时的浏览器。

发电机

生成器最初不被认为是处理异步控制流的一种方式，但它们在这方面的工作非常出色。生成器本质上是迭代器函数，允许通过使用 yield 暂停和恢复它们的执行。

yield 关键字本质上是说为这次迭代返回这个值，当你再次对我调用 next() 时，我会从我中断的地方继续。

生成器函数是特殊的函数，因为它们不会在第一次调用时执行，而是返回一个迭代器对象，上面有一些方法，并且能够在 for-of 循​​环和数组推导中使用。

send(),:这将一个值发送到生成器中，将其视为最后一个 yield 值并继续下一次迭代

next(),: 继续生成器的下一次迭代

throw():这会向生成器抛出一个异常，导致生成器抛出异常，就像它来自最后一个 yield 语句一样。

close():这会强制生成器返回执行并调用生成器的任何 finally 代码，这允许在需要时触发最终错误处理。

它们的暂停和恢复能力使它们在管理流量控制方面如此强大。

公司

Co 是围绕生成器的能力构建的，使处理流程控制更容易。它不支持您可以用生成器做的所有事情，但您可以通过它的使用来使用其中的大部分内容，而减少样板和头痛。出于流量控制的目的，我还没有发现除了 co 已经提供的东西之外，我还需要任何东西。虽然公平地说，我还没有尝试在流量控制期间将值发送到生成器中，但这确实带来了一些有趣的可能性......

还有其他生成器库，其中一些我能想到的就是挂起和 gen-run。我已经尝试了所有这些，co 提供了最大的灵活性。如果你还不习惯生成器，暂停可能更容易理解，但我不能权威地说。

就 Node 和最佳实践而言，我想说 co 目前正在赢得大量支持工具的支持。暂停最有可能获得亚军。

Co 与 promises 和 thunks 一起工作，它们用于 yield 语句，以便 co 知道何时继续执行生成器，而不必手动调用 next()。 Co 还支持使用生成器、生成器函数、对象和数组，以提供进一步的流控制支持。

通过生成数组或对象，您可以对所有生成的项目共同执行并行操作。通过让步给生成器或生成器函数 co 会将进一步调用委托(delegate)给新生成器，直到它完成，然后继续调用当前生成器上的 next，允许您使用最少的样板代码有效地创建非常有趣的流控制机制。

promise

虽然我说过我会将意见保持在最低限度，但我想说明的是，对我来说， promise 可能是最难理解的概念。它们是维护代码的强大工具，但很难掌握其内部工作原理，如果用于高级流程控制，可能会带来很多问题。

我能想到的解释 Promise 的最简单方法是，它们是由一个函数返回的对象，该函数维护函数的状态以及当对象的特定状态进入或已进入时要调用的回调列表。

promise 库本身不会很快消失。他们为包括 done() 在内的 Promise 添加了很多不错的东西，这些都没有进入 ES6 规范。更不用说相同的库可以在浏览器和 Node 中使用的事实，我们将拥有它们很长一段时间。

猛男

Thunk 只是接受单个参数回调并返回它们包装的另一个函数的函数。

这将创建一个闭包，允许调用代码实例化传入其回调的函数，以便在方法完成时通知它。

在我看来，Thunks 很容易理解和使用，但它们并不是所有事情的正确工具。例如， spawn 是创建 thunk 的主要痛苦，您可以做到，但这并不容易。

Thunks 与 Promises

这些不是相互排斥的，可以很容易地一起使用，但通常最好选择一个并坚持使用它。或者至少选择一个约定，以便您可以轻松分辨哪个是哪个。根据我的经验，Thunks 运行得更快，但我没有对其进行基准测试。其中大部分可能是因为它是一个较小的抽象，并且没有内置错误处理机制。

您通常会构建一些需要错误处理的东西，因此根据您的代码，thunk 的整体性能提升很容易平衡或偏向于 promise。

何时使用

生成器 - 当您可以安全地说您的应用程序将能够在最前沿运行时，无论是仅用于浏览器的 Firefox 还是 Node > 0.11.3

我一直在我现在离开的公司广泛使用它们，并且对它们允许的控制流机制和惰性评估感到非常满意。

Promises 与 Thunks - 这真的取决于你，以及你与每个人合作的舒适程度。它们没有提供相同的好处，也没有解决相同的问题。 Promises 帮助直接处理异步问题，thunks 只是确保一个函数接受其他代码传入所需的回调参数。

您可以同时使用它们，只要您可以保留它，以便很明显哪个不会有问题。

使用生成器的 Promises/Thunks - 我建议您在使用生成器进行控制流的任何时候都这样做。这不是必需的，但它更容易，就像使用 co 作为带有生成器的控制流的抽象更容易一样。要键入的代码更少，维护更容易，并且您遇到其他人尚未遇到的边缘情况的可能性也更少。

考阿

我不会详细介绍 koa。可以说它与 express 类似，但它是为了利用生成器而编写的。这确实赋予了它一些独特的优势，例如更容易的错误处理和级联中间件。以前有一些方法可以完成所有这些任务，但它们并不优雅，有时也不是最高效的。

特别说明:
生成器打开了一扇我们尚未探索的可能性之门。就像当它们不是最初的设计时它们可以用于控制流一样，我很肯定它们可以用来解决我们通常在 javascript 中遇到的许多其他问题。可能比我更聪明的人会发现我们还可以如何使用它们，但我至少会开始玩它们并更好地了解它们的能力。 ES.next 中还有更多关于生成器的好东西。