I know that "blocking" server architectures like Rails require you to offload time-intensive external API calls to worker processes (i.e. job queues) in order to prevent them from blocking the server process.
Is this also the case for node.js? Or does its "non-blocking" architecture mean that it can have incomplete external API calls in progress without rejecting or slowing down subsequent server requests?
The non-blocking nature of node.js and the implementation of the underlying networking in node.js does not use a thread for an external API call and is a very efficient implementation for that type of access.
No, this is not the case for node.js. It's non-blocking nature for networking will handle this for you without any "slowdown" consequences.
There are, of course, some system resources consumed per open socket and node.js may itself enforce some limits on the number of sockets it will open at the same time (I think the
httpmodule has a limit built in that can be configured), but this just means you either have to make sure you're not going hog-wild with lots of unfinished sockets open or that you carefully tune the configuration settings for your situation.Just to complete the picture, there are some types of I/O in node.js (such as file I/O) that do use an internal thread pool and the non-blocking nature of file I/O is implemented via actual threads, though this is almost entirely transparent to the node.js programmer. But, networking in node.js is not implemented this way (it uses actual non-blocking sockets).