I'm thinking about implementing an video converter using node.js with ffmpeg but since it's a cpu intensive task, It might block express from handling other requests. I've found a couple of articles about this and some of them use worker threads while others use queues like Agendajs or Bull.
Which one is more suitable for my use case? The video converter doesn't have to respond with the actual video, all it has to do is just convert it and then upload it into an S3 bucket for later retrieval.
Two sub-problems, here:
First problem is keeping your interface responsive during the conversion. If the conversion may take a long time, and you have no good way of splitting it into small chunks (such that you can service requests in between), then you will need to handle it asynchronously, indeed.
So you'll probably want to create at least one worker thread to work in parallel with the main thread.
The second problem is - presumably - making the conversion run fast. Since - as you write - it's a CPU intensive task, it may profit from additional worker threads. This could mean:
2a. several threads working on a single (queued) conversion task, simultaneously
2b. several threads each working on separate conversion tasks at the same time
2c. a mix of both.
The good news is that you really won't have to worry about most of this yourself, because a) ffmpeg is already using multithreading where possible (this depends on the codec in use!), providing you with a ready made solution for 2a. And b), node-fluent-ffmpeg (or node-ffmpeg) is already designed to call ffmpeg, asynchronously, thus solving problem 1.
The only remaining question, then, is will you want to make sure to run only one ffmpeg job at a time (queued), or start conversions as soon as they are requested (2b / 2c)? The latter is going to be easier to implement. However, this could get you in trouble, if a lot of jobs are running simultaneously. At the very least, each conversion job will buffer some input and some output data, and this could get you into memory troubles,
This is where a queue comes into the picture. You'll want to put jobs in a simple queue, and start them so that no more than n are running, concurrently. The optimal n will not necessarily be 1, but is unlikely to be larger than 4 or so (again, as each single conversion is making use of parallelism). You'll have to experiment with that a bit, always keeping in mind that the answer may differ from codec to codec.