Optimizing an API Response

As backend engineers, we frequently deal with API latency issues. It’s easy to create an endpoint and invoke a method when the endpoint is hit, but the real question is: Is that API efficient?

What is the response time? If it’s not a background task, anything over 1500 ms can feel excessive. Now, imagine you’re on a platform’s checkout page, ready to make a payment. You click “Pay,” and a message appears: “Do not refresh or press the back button.” But the screen gets stuck. Your money has been debited, yet you still don’t see a successful transaction. How frustrating would that be?

These situations often make the end users feel like switching to some other platform and use their services. The business can get affected and what not.

While keeping that scenario in mind, let’s shift our focus to the solution. It’s time to optimize our APIs.

Keep Payload size in check:

• Ever tried uploading an image to some platform and it says, the image should be within “x” kb/mb?
• Performance largely depends on how quickly the server is able to process the request.
• As you increase the payload size, it becomes more and more complex for the server to process the same and it might compromise on the latency while giving the response.
• Applications dealing with large image files often define limits to prevent the end users from uploading images beyond a certain size.
• This helps server to function smoothly.
• So, the next time a site asks you to reduce image size, don’t complain,,, just remember it’s for better performance! :)

Compress your API response:

• Let’s understand this with an example of Git ZIP file analogy.
• When we talk about compressing api responses, think of it like downloading a Git respository as a ZIP file.
• Here’s how: Imagine you are cloning a git repository. You have 2 options:
• Clone the entire repo with Git which pulls entire file and history as it is.
• Download it as a ZIP file that compresses the file into a smaller package making the download faster.
• In the same way, when your browser requests data from a server, instead of sending that huge data(like cloning an entire repo), it can compress the data/response (similar to zip file).
• This makes it faster to transfer the data across the internet.
• The only difference that lies here is that you manually extract the files whereas the browser does it automatically.
• The idea is to compress the size of the data to make the process more efficient.

Pagination:

• Imagine you are trying to buy a smartphone from Amazon in it’s Great Indian festival sale.
• If for a smartphone search request, Amazon loads all the smartphone at once on a single page it would lead to slower page load or it might even crash.
• To prevent this failure, you see somewhere around 20–30 smartphones per page and in the end you see a “Next” page button.
• This helps in smooth functioning of the backend servers as with less data(30 items) to handle, it can send back the response faster improving overall speed.
• Pagination basically means breaking down a large data set into smaller chunks that are easy to manage.
• Instead of showing all the data at once, you only display a small chunk of it.

Remove unnecessary processing on the server:

• This is one of the most avoided mistakes developers do in daily life.
• It might be overuse of printing logs in the console after every line or it might be making db calls every now and then.
• If there is some frequently accessed data, or maybe some calculation done on the same data repeatedly for different users, the application can cache the result and avoid hitting the db.
• This can result in significant load reduction on the db as well as it will help the server to retrieve results more quickly, improving overall performance.

Optimizing API responses is crucial for creating a good user experience. By keeping the above points in check, one can enhance his/her API’s performance.

Can you think of some other methods that might help us in improving our backend more in terms of api latency?

If you liked this post, do consider liking and you can also share and follow for more such content :).