Communicating with third party API

Question

I am working on an App which basically communicate with a third party API, it has no back-end. The front-end will be a SPA. Here is the overall scenario:

1. The external API needs current user's Id to respond to the requested query.
2. My server initially has the user information which it can use to query the API and get the desired result.
3. Based on the initial response the user fills in some more detail and requests the API again for the final response.

Possible solutions in my mind:

Solution 1(with additional requests overhead):

1. On first request serve the home page to the user, then let the front-end send a request(with the logged in user info) to my server to get initial data from the external API.
2. Now, my server requests the external API, gets the response and sends that response to the client.
3. Client gets the response, makes another request based on the response.
4. Repeat step 2 with the additional data.

Solution 2:

1. Since the server already has the user info(using oauth2), let it request the API first then render the landing page with the response loaded in the page as a static global JSON data, let the front-end code to query the static data and use it construct the next request.
2. Now, we have the same scenario of step 2 mentioned above.

PS: The API communicates via SOAP protocol and maintains a session using oauth2.

Question: Which scenario is better with respect to error handling and availability? How should I handle the case when the API is down?

Answer 1

So if I understand correctly the difference between the 2 solutions is really just in serving the 1st page if the external API is down:

• solution 1 is serving a generic (thus potentially useless) page
• solution 2 is serving a customized page (but with potentially stale cached info)

Both solutions will fail subsequent requests if the external API remains down, so really there isn't a significant difference between them from the error handling and availability perspective.

Personally I wouldn't design an app with such total dependency on the external API, I'd decouple a bit the requests to my app from the requests to the external API, in the sense that I'd always provide a response, even if that means just informing the user of the inadequate service status of the external API.

Something along these lines (where the long-lasting tasks would be your accesses to the external API): https://stackoverflow.com/questions/35030799/asynchronous-requests-in-appengine

Clarification: I consider the external API accesses as long-running because you have no control over how long it takes to get a response (if you even get one) in order for the app to process it and respond to the original client request. If the whole thing takes longer than 60 sec (the GAE request deadline limit) the app will be killed.

You could keep the synchronous calls to the external API as you intended (the app's "normal mode", when the external API responds in a timely manner), but with a safety timeout allowing the app to unblock, fallback to the "offline mode" I described in that Q&A, maybe record service status changes and still respond to the client's request accordingly, all within those 60s.