Best way to handle long running external api calls on the server?

Hello all,

My use case for parse is to do several api calls to chatgpt which can take anywhere from 1 sec to 30 seconds. Alex from Back4App had a video saying external apis in cloud code should be avoided because the response wait time can impact performance.

So Ive been potentially designing a system with 2 servers, one to handle secure, long running api requests and then parse server to handle crud operations.

But I was wondering if cloud jobs can do the job already. So if i want to call a long running api request, would it be wise to wrap it in a job and call the cloud job and that wouldnt slow down my other crud operations? If so, would it be wise to call a job from a cloud function (the docs seem to say jobs use http requests, so using a http request from cloud code to a cloud job…is that weird?). Then id subscribe to updates.

If im using jobs, if there any information on how it manages server resources? Id assume the server queues the requests until it can execute but i didnt see any documentation.

You can invoke Cloud Jobs from within Cloud Code and execute them asynchronously.

However, mixing operations with very different execution times can have other implications as well. For example, if a load balancer is distributing requests to a group of Parse Servers, then depending on the load balancing algorithm you may increase the load variance of these severs. It may also mess up your monitoring metrics because for example the execution times are not what end-users experience, but are corrupted by internal long-running operations.

1 Like

If you are using axios, you can specify timeout

I haven’t tried monitoring metrics or load balancing, so it’s hard for me to wrap my mind around these implications.

Let’s say my use case is that after save an object with some text. I then want to use a text-to-speech api to create an audio file and then store that on the object as well. I want the result ASAP.

Is option B actually more scalable or is it just extra complication?
A:

  1. Create the object
  2. After save, calls a cloud function that calls the text-to-speech api asynchronously
  3. store the new data on the object

B:

  1. Create the object
  2. After save, call a cloud function that calls a cloud job
  3. The cloud job calls the text-to-speech api asynchronously
  4. store the new data on the object

Why would you do that?

How about using the afterSave trigger of the object to invoke a Cloud Job that tiggers the text-to-speech API. The advantage of triggering the Cloud Job is that it comes with status tracking, so if the TTS API fails, you’d see that in the Job logs.

If you don’t care about status tracking, you could directly invoke the text-to-speech API in the afterSave trigger and log an error using the log adapter. Based on that you could trigger other things.