Is it bad practice for my backend to call 3rd party API's synchronously when processing a request?

Question

I use a third party API on my webapp that is accessed when the user requests a particular ressource. I'm worried that the successive API calls happening upon user's request might cause the user to wait a very long time and slow down my system (since the thread processing the initial request is also waiting on these API calls to return).

so basically client -> server ->x3 third party API (three successive calls are needed)

Details: these API calls login in the user with the 3rd party system and return a session token. Currently using Django in the backend.

Is doing this synchronously always a bad idea this way? I've considered creating an asynchronous architecture instead and serving it to the user via websocket, but I'm hesitating because of the perceived added complexity of design.

• Caleth: Does the 2nd request depend on the result of the 1st?
• Bart van Ingen Schenau: Can the user make a useful second request to your server before the session token from the 3rd party server is available to the client? Note that in a properly implemented framework, a thread that sits waiting for an external event consumes only some memory and hardly any processor time.
• Walfrat: If this only apply to a login operation, you may let it be, having a login slower than others screen of an application is perfectly acceptable. Of course if "slower" means 30s you have a problem, if it is 3s, it's fine.
• Laiv: might cause the user to wait a very long time and slow down my system. Seems premature optimization to me. Take a look to this question.
• Jad S: the third party API is a service called Yodlee. Right now I'm using the test version and it's slow but I don't know how it will be in production. The requests do depend one on the other.

Answer 1

Synchronous calls for this purpose are fine, especially if you need the result of the call to continue processing the request.

You should do that asynchronously if you have a reason to do so. Many people don't realize it but doing something asynchronous or in parallel can create a lot of problems and there is a lot of complexity even it's well hidden (like the C# async/await).

So, if you

• can continue processing the request without having the response from the 3rd party API but that data must be in your response (i.e. you can do other things in parallel with waiting for the response)
• don't really need it to continue but it's nice to have it, however doesn't really matter if it is or isn't in your response (i.e. you can do other things in parallel with it but don't wait for it - if it doesn't return in time, you can send your response anyway)
• don't need it at all for this request and can send it to the client later

you should do it asynchronously. The first case is probably most common.

In your particular case, you probably need the user to be authenticated and authorized before continuing processing the request. So I would do it synchronously. Another question are the 3 successive calls. Can they be in parallel? Then you can do it and wait for all 3 to be completed. If not, can you ask for changing the API to allow for only one call? This would be the 'right thing to do' however it's usually impossible.

• Jad S: Unfortunately there doesn't seem to be a 1 call scheme and the output of 1 goes into the input of the next. However, I'm considering pre-calling and caching the responses

Answer 2

Synchronous isn't uncommon. Websockets for that purpose would be weird.

Sounds like your comms follow a request/response pattern, so HTTP is the right answer. If you choose to write "synchronous" code on the client, the O/S will give the cycles to other processes.

On the server, it's OK to put three back end calls in series like that. It isn't the greatest, but it's common enough. You're not going to save any resources by using WebSockets.

• Jad S: As I commented on my question post, I'm wondering about passing the job to a worker pool before it is needed and caching the API response values. Would that be a sensible alternative?
• John Wu: Before it is needed? Don't know how you'd do that (class CrystalBall perhaps?) You probably shouldn't cache those third party sessions for too long, as they could time out, or take up resources on the third party server that you don't yet need. Might also incur additional transaction fees or violate terms of use if you did that.

Answer 3

If you can do it async then you should.

However, unless the calls can be run in parallel then the benefit of doing them async will depend on your server technology.

Unless you are freeing up the processor time to do other stuff theres no point. So make sure that your entire request process is running async. Not just blocking untill the async api call returns.

In most cases this wont be a massive change. If you are doing .net then you just need to add the async keyword to your webapi method for example.

It sounds from your question that you want to remove your server from the equation and just have the client goto the third party directly?

This would obvs cut out your server costs, but you might need that server to hide your api key or something.

• Jad S: Hi! I'm using Django in the backend. The frontend querying directly would be the best but I have credentials I don't want to pass to the client. I guess what I'm mainly asking for a sanity check that my current synchronous scheme isn't right off the bat a stupid idea
• Ewan: no it seems fine. I think maybe the 'asyncness' isnt your real question though