Does Heroku use Node.js preventing the need for queues + dynamic workers for 3rd party API calls?
The Heroku Dev Center on the page about using worker dinosaurs and background jobs states that you need to use worker + queues to handle API calls like fetching an RSS feed, as the operation can take a while if the server is slow and doing this on the web dino will cause it to be blocked from receiving additional requests.
However, from what I've read, it seems to me that one of the main points of Node.js is that it doesn't suffer from blocking under these conditions due to its event-based asynchronous runtime model.
I'm confused because that doesn't mean that it would be okay to make API calls (asynchronously) on web speakers? Perhaps the docs were written more for Ruby / Python / etc use cases where the synchronous model was more common?
source to share
NodeJS is an implementation of a reactor schema . NodeJS uses 5 reactors by default. As soon as these 5 reactors are used for IO-related tasks, the main event loop will block.
A common misconception about NodeJS is that it is a system that allows you to do many things at once. This is not necessarily the case, it allows you to do other things while waiting for IO-related tasks up to 5 at a time.
Any tasks bound to the CPU are always executed in the main event loop, which means they will block.
This means that if your "work" is IO-bound, like putting things in databases, then you might be able to avoid using speakers. This, of course, depends on how many things you plan to continue. Remember that any task you put into the main application will take resources from other incoming requests.
Generally, it is not recommended for things like this, if you have a job that does some processing, it belongs in a queue that runs in its own process or thread.
source to share