How to design an efficient APIs network with FASS?
Please bear in mind that what you see here is not an exact reflection of reality, it’s a simplified explanation of a specific use case in which all possible issues have been grossly emphasized to provide an overview of the network communication concerns that API designers must consider when designing APIs.
We want to talk about the API/Dashboard application which provides some logs for your services, so you can have a service or more than one services.
What is the problem?
Have you ever thought, Why do the App’s users complain? Why is this application slow and inefficient? and Why the owner concerned about the costs?
Let’s start by decomposing an API network call made over the mobile network.
The first step is to connect to the server hosting the App API which consists of various actions involving the user’s internet quality, low-level network communication initiation, and encryption. We will assume that it always takes around 300 ms, but know that depending on the type of users networks such as internet quality, etc. (This time is often called the latency)
When the server receives the request, it has to process it, load the logs from the database, and generate a JSON document. We’ll assume that this takes 20 ms, but the actual time depends on what is requested and the server’s capabilities.
Finally, the fourth step consists of downloading the server’s response. We’ll assume the generated JSON document’s size is around 32 KB, so it takes 200 ms to download it at 160 KB/s (which is advertised as 1.3 Mb/s).
the time of this single request alone is not bad, but let’s see what happens when the App actually uses the API to populate the dashboard screen for the simplest use case: a user corresponding to a single owner who has a single account.
in the above picture, you can see, which API calls are made and how. To simplify the explanation, we will take it for granted that the network bandwidth is 160 KB/s, the latency is always 300 ms, sending the request always takes 0 ms, and it always takes 20 ms for the server to process a request.
To load the data shown on the dashboard screen, The whole API call chain consists of five API calls, distributed in three steps thanks to the parallel calls. Unfortunately, it takes 1.2 s, which is above 500 ms, the top end of the acceptable latency range. Now let’s see how it goes with a more complex one.
In the above picture you can see, The app starts again by listing owners, but this time there are four of them. Because the application is limited by the operating system to four concurrent HTTP connections, it reads the detailed information for each of the account owners using four parallel requests; after that, it lists their accounts, also in parallel. Note that if the whole network bandwidth is 160 KB/s, each parallel request is made at a quarter of it or 40 KB/s. Depending on how often users/owners check their services, the App could use around 60 to 90 MB of data per month.
Nowadays data use isn’t really a problem for most users in most countries, but that’s not true for all users everywhere. But beyond the data plan, the most annoying thing is that all the API calls made on each screen drain the device’s battery because they keep the radio/wifi up and running for a longer period of time. Clearly, the number of calls, their length, and the data volume exchanged can be of concern on the consumer’s side, but the same can be true on the provider’s side.
Let's say the API is hosted on AWS, The API is implemented using the serverless service(FAAS) called AWS Lambda.
Each goal is coded independently as a function, and there is no more need to worry about servers, applications, and scaling. The systems handle everything, when calls arrive, each corresponding function is run. The pricing of the service is based on the number of calls received, the processing time, and the outgoing data volume.
Also, AWS Lambda gives you some facilities like an online editor and etc.
There is only an example. APIs can have different contexts than those we have just seen, but the network efficiency dimensions will usually resolve around these factors: speed, data volume, and number of calls. We have to be aware of that and try to find a balance between the need for efficiency and an ideal design.
Thank you for reading
In the next, we will talk about balance and optimize network communication.
Resources:
