bottleneck VS bull

bottleneck

I tried to use the Bottleneck library to rate limit a script that needs to make a lot of calls to a 3rd party API in Deno. However, to my surprise it just has no effect, even when tested on small toy examples. I didn't try it in Node or the browser. Is there a reason why this library just wouldn't work on the Deno runtime? Is there a good alternative? It's a hard thing to google for because results tend to be either cron or server-side libraries.

If you have trouble with floods of traffic, use a rate limiter. Check out https://www.npmjs.com/package/bottleneck

Perhaps some streaming (native streams or some observables like rxjs) solution combined with rate limiting like https://www.npmjs.com/package/bottleneck ?

In general, you should avoid reinventing the wheel, so we looked for libraries which could solve our problem. We found BottleneckJS and decided to try to use it for our initial prototype.

Between tiny-async-pool and bottleneck I can suck data from any api very efficiently and within rate limits

Ah, this looks really nice! https://www.npmjs.com/package/bottleneck

As we can see here, in order to not violate the rate limiting rule, we must have 5 attempts at the API per minute or wait at lease 200 milliseconds between the executions. This was not that hard, but wait, JavaScript is asynchronous in nature. How will we make it run synchronously and sequentially ? The real question we are actually asking is, how do we make it that the HTTP requests to the remote API will wait the minimum delay time in between the executions. This is where we are going to use the tool that is called BottleNeck.

To implement the solution with a queue, I used a package called 'Bull' (https://github.com/OptimalBits/bull). It's a library that helps with distributed job control, providing some very useful solutions for this type of work, such as background job processing, queues with priorities (FIFO, LIFO, and others), among other features. 'Bull' uses Redis for queue storage, so if your application crashes for any reason, once it's back online, it will continue executing the processes that are in the queue. In our case, we'll use the FIFO (First in, first out) queue solution, meaning priority based on arrival order.

We use bull-js for our distributed queue and event-driven library.

I'm using the excellent Redis based Bull.js as a job queue on Kubernetes.

For Job Queue, NestJs provides a package named @nestjs/bull as an abstraction/wrapper on top of Bull, a popular, well-supported, high-performance Node. js-based Queue system implementation.

I'm working on a large ETL project that involves handling queues for file integration. Currently, we are using Redis with Bull (https://www.npmjs.com/package/bull) for this purpose. However, to streamline our architecture and address security concerns, we are considering migrating the queue to PostgreSQL.

BullMQ is a pretty solid choice: https://github.com/taskforcesh/bullmq It's the successor of Bull: https://github.com/OptimalBits/bull

For Node specifically, things like Streams, understanding the asynchronous model completely, and the event loop. Also, queues tend to get used a lot in Node, so understanding the basic concepts behind that and how to use something like bull would be useful.

To do this properly, you need to put the task into queue, so if there are 1000 simultaneous uploads it won't kill your server but will be processed one by one. For the queue, see bull. Image hostings like AWS have some functionality for processing on their side, as an option.

This is a memory intensive process though and Heroku is OOM'ing with R14 errors. For this they recommend migrating intensive work like this to a Background Job via Redis, implemented in Bull and Throng