How to boost the performance of your APIs - Part I

Customer expectations are shaped by the best digital experiences delivered by companies like Apple, Facebook, Google, AirBnB, Uber, and Amazon. Fulfilling these high expectations demands that your App be powered by highly performing APIs.

Adam Ali - Digital Transformation Expert

. Adam Ali 🦋 . May 29, 2018
20 . 3

Overview

There are several problems that surface after a business going through Digital Transformation (DX) launches its first few APIs. One key problem is the poor performance of these APIs especially if the API is consumed at a rate of more than 10 TPS (Transaction per Second).

Typically when poor performance is investigated for a root cause, it almost always lead back to:

How the project measured success for the delivery of the APIs,
How the APIs were designed; and
How effective the Quality Assurance (QA) that was done for them.

This article is one in a multi-part series which aims to outline the three key pillars to boost API performance.

Why do you need to care about the performance of your APIs?

Multiple occurrences of delays in the APIs powering your app is likely to lead users to abandon it in favour of another better performing app. With millions of Apps on iOS and Android App stores, receiving only a few bad ratings or negative reviews on your app would have a negative impact on the app in-terms of discoverability, conversion and effective advertising.

As you can see from the above illustration, low rating and bad feedback negatively affects your company's image and customer perception of your ability to deliver better Apps. The above screenshots are real ones taken for three different slow Apps developed by three of the top organisations in Australia.

APIs are the backbone of the products and services your company delivers to their customers, thus they need to perform very well in order for your App to deliver the best customer experience possible.

How to overcome the challenge? The Solution

The 3 key pillars to boost API Performance are:

1	Assess, measure & define target performance metric
2	Standup Automated API QA Capability
3	Ensure that performance is designed into the solution powering your APIs (Performance by design).

In this part of the series, Part I, I will be focusing on the first pillars one and two, while in Part II of the same series, I will discuss the third pillar in detail.

1. Assess, measure & define target performance metric

Assuming you already have APIs that are already being consumed, the first thing we need to do is to assess whether we have a performance problem or not. If there are any performance problems, which APIs are impacted? how degraded the performance is compared to the target performance metric that need to be achieved. For the APIs impacted we need know:

1	At what rate are these APIs being consumed (50 TPS, 100 TPS, 150+ TPS)?
2	How big is the size of the response of these APIs (mainly the Payload)?
3	From where are these APIs are being consumed?
4	At what time of the day do these APIs reach highest TPS (Peak times)?
5	What is the current average response time for these APIs? and what is the target response time that need to be achieved to avoid impacting the customer experience.
6	Any outages when rate of consumption is over a certain TPS? if yes, how long does it take for the APIs to recover?

If you havent published your APIs for consumption yet, then you need to go through an exercise of making some assumptions about the expected usage of your APIs after publishing. The assumptions still need to answer the key questions mentioned above.

To continuously assess and measure API performance, it is paramount that some type of API Operational Intelligence capability be stood-up. Please refer to my article How API Operational Intelligence solves critical business challenges for more details.

At this point, you know what the performance problems are and you have a target performance metric that need to be achieved. The best way to achieve high performance metric is ensure that performance is designed into the solution powering your APIs (Performance by design).

Assuming you have the design that can deliver high performing APIs, you will still need to do the QA on the APIs to assess it against the target performance metrics. So you would need to standup the Automated API QA first. In Part II of the same series, I will be focusing on how to design highly performing APIs that can continuously perform without interruptions even with unexpected load or unplanned outages.

2. Standup Automated API QA capability

To Standup an End-2-End Automated API QA capability, we need to develop an Automated API DDT (Data Driven Test) Framework. The API DDT Framework contains re-usable test logic that reads test data from a spreadsheet, makes API calls, and asserts on the response of those API calls. The Framework also logs test step details to be used in the generation of the test report.

The digram below outlines the design of the Framework at a high level.

1	In this step, the framework reads test data from a spreadsheet
2	Using the data retrieved in step 1, the framework executes the test case by making an API call and asserting on the API call response.
3	The framework logs test step details to be used in the generation of the test report.

Now you have the framework, you need to embed it into your CI/CD Pipeline to make it fully automated with your code releases. The digram below outlines the End-2-End architecture design for the Automated API DDT Framework embedded in the CI/CD Pipeline. Here I'm assuming you are using AWS CodePipeline but you can also use any other CI/CD Pipeline.

1	In this step, the API QA Test Analyst would be preparing the API Automated test cases by filling a spreadsheet with a row for every test step. The test step row in the spreadsheet would have API request parameters as well as response parameters for assertions. During preparation, the API QA Test Analyst would be expected to execute the framework to see if there are any problems with the prepared test cases.
2	After the preparation of test cases, the API QA Test Analyst would push the spreadsheet to GitHub API Project repository under test folder. Also the SQL statements for test data would be pushed as well.
3	AWS CodePipeline would detect that there is an update in the API GitHub repository which in turn would initiate a pull request of the entire project including the test folder to start the build, deploy and test steps.
4	In the AWS CodePipeline Test step, the first step is to load the database with the necessary test data required for the test cases to be executed.
5	AWS CodePipeline would place the spreadsheet on the Test Server (Test Server here is Running SmartBear ReadyAPI Desktop version installed on a AWS Linux Machine) and then execute the Functional, Security and Performance test cases.
6	The ReadyAPI server (where ReadyAPI Desktop version is installed) starts executing the test cases uploaded in the previous step. As a result API calls are made to the API Gateway then on to the APIs and a response is returned back where assertions would be checked. Test results and data would be stored for generating the test report later.
7	After all test steps are executed, the test report would get generated and uploaded to AWS S3.
8	A notification (Email/SMS/Push) would be sent to the relevant parties to notify them with the completion of the QA on the APIs in-scope.

As part of standing up the automated API QA, you would need an API DDT (Data Driven Test) framework to make things super easy at implementation and cut down on the time taken to develop automated test case.

Bonus: Automated API DDT framework

With this article, I'm giving away a tested Automated API Framework based on DDT (Data Driven Test) so that you can get a head start in standing up the Automated API QA capability.

Automated API QA DDT Framework Illustration

The framework caters for functional, security and performance testing of APIs. The framework can be accessed and downloaded from GitHub. The Framework was built using SmartBear ReadyAPI test QA software.

Conclusion & Takeaways

Notice of Non-Affiliation and Disclaimer: The author of the article is not affiliated, associated, authorized, endorsed by, or in any way officially connected with any of the product vendors (Apple, Facebook, Google, AirBnB, Uber, Splunk, Amazon AWS, or SmartBear) mentioned in this article, or any of its subsidiaries or its affiliates.

Data Driven Tests
API Testing Framework
Test Automation Framework
Test Automation
Regression Testing
Functional Testing
ReadyAPI
SmartBear

Share article with others on your favourite social media network

About the Author

Adam Ali 🦋

I'm End-2-End Digital Solution Architect with 16+ years of experience in design, development, and integration of end-2-end robust solutions with particular attention to security, high performance, scalability and high availability.

All author posts