A side project I'm working on with some friends currently deals with an API interface that, for many reasons, is slow and cannot be changed to improve speed. I'm talking API responses that take anywhere from 5 seconds to 25 seconds. It's old software, but we have to integrate with it, period. After that API response comes back, we write to a database and then update the UI to reflect the updated state.
The problem is, our users will need to perform actions that use this API up to 100 times a day. Obviously it would be inefficient to block the UI until the response comes back, but the overhead of dealing with a second async call to the API before the first one responds is also difficult to maintain and to write. Any ideas on a better solution than I can think of?
I should note I am writing this all on a MEAN stack.
Best Answer
You don't have to block the complete UI before the response comes back. You only have to disable the parts of the UI which allow to make another API call before the first one is processed completely (in an asynchronous operation, of course!).
If that is feasible or not depends heavily on the UI, the features of your application and how they are tied to those API calls.
You might also rethink why this is the case, and if it is really so difficult as you say. I assume your UI is already event driven. So it has to deal with all kinds of events from different sources coming in in arbitrary order. A "respond event" should not be different from this, the only thing you have to make sure is any respond event does not rely on some global state caused by the related previous request event. Instead, the whole information package you get from a respond event should be self contained, not relying on the fact the latest former "request" event was exactly the one which belongs to the next incoming respond. If this is possible depends on the API and how it is integrated into your system in detail.
Indepently from allowing the users to initiate multiple API requests before the responds come in, or not, there should be some visual feedback in the UI informing the user about the open requests. Disabling the API related parts in the UI until the request comes in is probably the simplest form of giving the user this feedback. If you want to allow API requests without blocking the next one, the user should still know the "button he pressed" to initiate the request (for example) was sucessfully hit by him. The UI may show a list of open requests, an increased counter, maybe a progress bar or something like that, so he does not try to press "the button" several times to force a reaction.