Bull: Is this library really needed inside the javascript ecosystem?

[pbassut]

The reason for the question is because celery is way more popular in python than bull is in javascript. Maybe because of the async nature of javascript. For example, celery came around for cases where you didn't want to hang the request and "delegate" work to another thread.
But in javascript, if you don't await a promise, it won't hang the request, but the processing will happen.

It's a very basic question, but important, since I'll take this into consideration when architecting my systems.
Sorry if this sounds like council, but I think it's helpful for other people thinking about they if they should hit a specific nail with this hammer.

I already use this project. I'm thinking about using it again on another one thus the question

[rxhl]

@manast

I think @pbassut has a fair point. Node (and its event loop) by default provides async/await features where the incoming requests are not be blocked due to existing requests. This is different from flask/django that don't have a concept of event loop and so they need to delegate tasks to Celery so they can keep processing incoming requests.

Bull really shines when the requests are CPU-intensive and will block the event loop. For I/O related events, I think node alone would do just fine.

[stansv]

@rxhl Basically Bull offers a persistent queue on top of Redis, with API convenient to setup robust clustered processing of background jobs. That's for what it was designed. You don't need to use it if you just serving synchronous client requests.