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.

1 Answer 1


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.

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

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.

  • Yeah, we had discussed that possibility as well. We may end up going that route, although it is kind of painful to only disable certain objects on the client side haha Commented Oct 4, 2017 at 17:28
  • 2
    @DanielFullerton: this is a tradeoff: either it is too painful for the user when you disable all objects, or it is too painful for you to implement disabling of the right subset of those UI objects. Pick your choice.
    – Doc Brown
    Commented Oct 4, 2017 at 20:07
  • it is not necessarily the pain of implementation, so much as the issue of performance. The result set we're dealing with is rather large, and our target machine not too powerful. So, iterating through an array of large objects in an already heavy UI (AngularJS-based) is not desirable, but I feel your answer may be the best solution. Commented Oct 5, 2017 at 12:02
  • @DanielFullerton Unless your iteration is constant (polling rather than event-driven) O(n) doesn't seem so bad for just UI updating.
    – JAB
    Commented Oct 5, 2017 at 19:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.