Worker thread in Twilio’s serverless function?

Question

I’m building a voice application with Twilio’s serverless functions, I need a run a process after gathering user speech input form an incoming call that can take > 15 secs to execute thus resulting in timeouts, I was thinking I could put the call on hold / into a conference, start a worker thread for processing, after which I could modify the call on hold and provide the processed data.

I’ve verified that I can use a worker thread to process required data and modify the call on hold.

But I’m not sure if it’s possible, and if yes, how to specify the path and name of the worker thread js file.

E.g. How can specify worker.js in the following snippet?

const { Worker } = require('worker_threads');

// Create a new Worker Thread

const worker = new Worker('./worker.js', { workerData: { /* data */ } });

worker.on('message', (result) => {

  // Do something with the result

  console.log(result);

});

If this is not possible, any suggestions on what other options I should explore? Or is Twilio’s serverless functions not a good fit for my requirements?

Answer 1

I'm afraid a serverless environment cannot solve the issue you are describing. Serverless functions usually have a maximum execution time. For example, Twilio serverless functions have a maximum execution time of 10 seconds. Similarly, many others also have a maximum execution time. This inherently is not sufficient for long-running processes. Even if you could use the Workers API (which many serverless platforms don't support), your main function would still sit idle and wait, and hence exceed the max execution time.

PS: Even if you found a serverless runtime that has a max execution time that just fits your needs, it's probably unfeasible to use serverless since you pay per execution time.

I'd suggest running this process on a traditional (non-serverless environment). Maybe it's possible to call another Twilio serverless function via a webhook once your long-running process is done. This way, you could continue having all the Twilio logic on Twilio serverless and only host the other code somewhere else.