Why So many People Get Asynchronous Calls in APIs Wrong

I had three different conversations with people and companies this week about asynchronous API’s and am amazed and how little people still understand about how this is done. People still think that simply because API’s are ‘reactive’, this solves everything magically somehow. Its not until afterward that they will be surprised at all the issues they will be confronted with.

Asynchronous handling of request is great and I do it myself but to be able to do it, you must first fix the call flow and move communications AWAY from the controllers… this is what I commonly refer to as API Abstraction.

If you are doing asynchronous request handling in the controllers/services, you are missing all the request handling that is done beforehand by the filters and even being duplicitous in your handling and doing twice as much work.

The Controller is meant to do Business logic; get data from Model, process data and return it. It is not meant to handle communications and communication checks. These checks have to happen on every controller and in every method as a result of binding communications to biz logic. And asynchronous tasks have to do double duty to perform all these tasks AND the data processing before they can return.

Through API Abstraction, you can perform asynchronous tasks on prechecks of request and postchecks of response separate of data processing. This reduces code and greatly increase code portability and speed.

To date, the vast majority of people still push asynchronous code within the model of ‘centralized architecture’ ideals and have not advanced their thinking to ‘distributed architecture’ thinking yet. Perhaps one day though… 🙂