Original author of the library here. Will take any questions and comments, thanks!
EDIT: After posting this I just found out the library isn't compatible with the latest node release (6.5.0; still works well with 6.4.0). Will work with nodejs to see how we can address the problem.
The example given in the readme (API pagination) seems better suited to an observable or stream to me, but it left me curious about applicability to other use cases with Promises.
One is retries on failure or timeout. The other is waiting for something to execute a certain number of times. The latter is something I've used only in tests, but it might have other uses I'm not thinking of. I've implemented both of these in the past with recursion, which is great, but scares some folks, esp when mixed with promises.
I guess it was inevitable that Javascript support for this would lead to people yet again rediscovering the bad idea that is Seaside-style continuation-based web programming.
Please don't actually do this. It completely violates all expectations of how both user-facing web servers and REST endpoints are supposed to behave.
The stateless nature of web programming is always frustrating, but attempts to use continuations to pretend a sequence of http requests can be treated as a single linear thread of execution simply don't work.
Well, I guess states need to be captured somewhere somehow in order for any computer programs to function. The point of this library is to give a more declarative way of doing it, rather than having them dispersed into different parts of asynchronous handling logic.
It is one thing to say that a protocol is designed to be stateless, it is quite another to say a particular programming technique is so. If anything, functional programming leads to programming style that concerns less with how a particular state leads to another, and more with what transitions we want to make.
8 comments
[ 1.8 ms ] story [ 28.6 ms ] threadEDIT: After posting this I just found out the library isn't compatible with the latest node release (6.5.0; still works well with 6.4.0). Will work with nodejs to see how we can address the problem.
One is retries on failure or timeout. The other is waiting for something to execute a certain number of times. The latter is something I've used only in tests, but it might have other uses I'm not thinking of. I've implemented both of these in the past with recursion, which is great, but scares some folks, esp when mixed with promises.
With regards to your first comment, I'm actually considering porting some of the logics to rxjs or other reactive extensions.
Please don't actually do this. It completely violates all expectations of how both user-facing web servers and REST endpoints are supposed to behave.
The stateless nature of web programming is always frustrating, but attempts to use continuations to pretend a sequence of http requests can be treated as a single linear thread of execution simply don't work.
It is one thing to say that a protocol is designed to be stateless, it is quite another to say a particular programming technique is so. If anything, functional programming leads to programming style that concerns less with how a particular state leads to another, and more with what transitions we want to make.