I'm not sure what you mean by "horde promises in odd places"--you use a promise whenever something is happening asynchronously, certainly, but I'm not sure what's odd about that. Maybe this is an antipattern I haven't encountered yet?
I think producer/consumer and promises cover two different use cases (with some overlap). Indeed, when I have a work queue it frequently involves promises: queueing a work item returns a promise which will resolve when the work is complete, and part of executing a work item is returning a promise so the consumer knows when the task is done and can start in on another one.
I have seen paths that will generate upwards of 10 promises and then put them together at the end. In theory, this shouldn't be a problem and the code was readable enough. Reasoning about all of the different ways backpressure can happen was not as easy.
Compared to knowing that you have a set of queues that ultimately feed into other queues. It is much clearer to reason about the throughput of individual queues and take that into consideration when designing new queues in the system.
It is basically like someone throwing a ton of outlets on a wire going through a room. I mean, yes. You can do that. Often won't even cause issues. However, for large enough systems, you ultimately need to know what the load on that circuit will be and it is not acceptable to put yet another plug extender there.
Comments
I don't actually see how promises help. In particular, it seems to encourage people to build systems that basically horde promises in odd places.
I greatly prefer first class models for where things queue up, and then to use producer/consumer objects against those queues.
I'm not sure what you mean by "horde promises in odd places"--you use a promise whenever something is happening asynchronously, certainly, but I'm not sure what's odd about that. Maybe this is an antipattern I haven't encountered yet?
I think producer/consumer and promises cover two different use cases (with some overlap). Indeed, when I have a work queue it frequently involves promises: queueing a work item returns a promise which will resolve when the work is complete, and part of executing a work item is returning a promise so the consumer knows when the task is done and can start in on another one.
I have seen paths that will generate upwards of 10 promises and then put them together at the end. In theory, this shouldn't be a problem and the code was readable enough. Reasoning about all of the different ways backpressure can happen was not as easy.
Compared to knowing that you have a set of queues that ultimately feed into other queues. It is much clearer to reason about the throughput of individual queues and take that into consideration when designing new queues in the system.
It is basically like someone throwing a ton of outlets on a wire going through a room. I mean, yes. You can do that. Often won't even cause issues. However, for large enough systems, you ultimately need to know what the load on that circuit will be and it is not acceptable to put yet another plug extender there.