Cache API responses

This tutorial will focus primarily on handling caching at the API Gateway level by using Apache APISIX API Gateway and you will learn how to use the proxy-cache plugin to improve response efficiency for your Web or Microservices API.

Here is an overview of what we cover in this walkthrough:

Improve performance with caching

When you are building an API, you want to keep it simple and fast. Once the concurrent need to read the same data increase, you’ll face a few issues where you might be considering introducing caching:

  • There is latency on some API requests which is noticeably affecting the user’s experience.
  • Fetching data from a database takes more time to respond.
  • Availability of your API is threatened by the API’s high throughput.
  • There are some network failures in getting frequently accessed information from your API.

Caching in API Gateway

Caching) is capable of storing and retrieving network requests and their corresponding responses. Caching happens at different levels in a web application:

  • Edge caching or CDN
  • Database caching
  • Server caching (API caching)
  • Browser caching

Reverse Proxy Caching is yet another caching mechanism that is usually implemented inside API Gateway. It can reduce the number of calls made to your endpoint and also improve the latency of requests to your API by caching a response from the upstream. If the API Gateway cache has a fresh copy of the requested resource, it uses that copy to satisfy the request directly instead of making a request to the endpoint. If the cached data is not found, the request travels to the intended upstream services (backend services).

Apache APISIX API Gateway Proxy Caching

With the help of Apache APISIX, you can enable API caching with proxy-cache plugin to cache your API endpoint’s responses and enhance the performance. It can be used together with other Plugins too and currently supports disk-based caching. The data to be cached can be filtered with responseCodes, requestModes, or more complex methods using the noCache and cacheByPass attributes. You can specify cache expiration time or a memory capacity in the plugin configuration as well. Please, refer to other proxy-cache plugin’s attributes.

With all this in mind, we’ll look next at an example of using proxy-cache plugin offered by Apache APISIX and apply it for ASP.NET Core Web API with a single endpoint.

Run the demo project

Until now, I assume that you have the demo project apisix-dotnet-docker is up and running. You can see the complete source code on Github and the instruction on how to build a multi-container APISIX via Docker CLI.

In the ASP.NET Core project, there is a simple API to get all products list from the service layer in ProductsController.cs file.

Let’s assume that this product list is usually updated only once a day and the endpoint receives repeated billions of requests every day to fetch the product list partially or all of them. In this scenario, using API caching technique with proxy-cache plugin might be really helpful. For the demo purpose, we only enable caching for GET method.

Ideally, GET requests should be cacheable by default - until a special condition arises.

Configure the Proxy Cache Plugin

Now let’s start with adding proxy-cache plugin to Apache APISIX declarative configuration file config.yaml in the project. Because in the current project, we have not registered yet the plugin we are going to use for this demo. We appended proxy-cache plugin’s name to the end of plugins list:

  1. plugins:
  2.  - http-logger
  3.  - ip-restriction
  4.  …
  5.  - proxy-cache

You can add your cache configuration in the same file if you need to specify values like disk_size, memory_size as shown below:

  1. proxy_cache:
  2.  cache_ttl: 10s # default caching time if the upstream doesn't specify the caching time
  3.  zones:
  4.  - name: disk_cache_one # name of the cache. Admin can specify which cache to use in the Admin API by name
  5.  memory_size: 50m # size of shared memory, used to store the cache index
  6.  disk_size: 1G # size of disk, used to store the cache data
  7.  disk_path: "/tmp/disk_cache_one" # path to store the cache data
  8.  cache_levels: "1:2" # hierarchy levels of the cache

Next, we can directly run apisix reload command to reload the latest plugin code without restarting Apache APISIX. See the command to reload the newly added plugin:

  1. curl http://127.0.0.1:9180/apisix/admin/plugins/reload -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT

Then, we run two more curl commands to configure an Upstream and Route for the /api/products endpoint. The following command creates a sample upstream (that’s our API Server):

  1. curl "http://127.0.0.1:9180/apisix/admin/upstreams/1" -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d '
  2. {
  3.   "type": "roundrobin",
  4.   "nodes": {
  5.     "productapi:80": 1
  6.   }
  7. }'

Next, we will add a new route with caching ability by setting proxy-cache plugin in plugins property and giving a reference to the upstream service by its unique id to forward requests to the API server:

  1. curl "http://127.0.0.1:9180/apisix/admin/routes/1" -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d '{
  2.   "name": "Route for API Caching",
  3.   "methods": [
  4.     "GET"
  5.   ],
  6.   "uri": "/api/products",
  7.   "plugins": {
  8.     "proxy-cache": {
  9.       "cache_key": [
  10.         "$uri",
  11.         "-cache-id"
  12.       ],
  13.       "cache_bypass": [
  14.         "$arg_bypass"
  15.       ],
  16.       "cache_method": [
  17.         "GET"
  18.       ],
  19.       "cache_http_status": [
  20.         200
  21.       ],
  22.       "hide_cache_headers": true,
  23.       "no_cache": [
  24.         "$arg_test"
  25.       ]
  26.     }
  27.   },
  28.   "upstream_id": 1
  29. }'

As you can see in the above configuration, we defined some plugin attributes that we want to cache only successful responses from the GET method of API.

Validate Proxy Caching

Finally, we can test the proxy caching if it is working as it is expected.

We will send multiple requests to the /api/products path and we should receive HTTP 200 OK response each time. However, the Apisix-Cache-Status in the response shows MISS meaning that the response has not cached yet when the request hits the route for the first time. Now, if you make another request, you will see that you get a cached response with the caching indicator as HIT.

Now we can make an initial request:

  1. curl http://localhost:9080/api/products -i

The response looks like as below:

  1. HTTP/1.1 200 OK
  2. …
  3. Apisix-Cache-Status: MISS

When you do the next call to the service, the route responds to the request with a cached response since it has already cached in the previous request:

  1. HTTP/1.1 200 OK
  2. …
  3. Apisix-Cache-Status: HIT

Or if you try again to hit the endpoint after the time-to-live (TTL) period for the cache ends, you will get:

  1. HTTP/1.1 200 OK
  2. …
  3. Apisix-Cache-Status: EXPIRED

Excellent! We enabled caching for our API endpoint.

Additional test case

Optionally, you can also add some delay in the Product controller code and measure response time properly with and without cache:

  1.  [HttpGet]
  2.  public IActionResult GetAll()
  3.  {
  4.  Console.Write("The delay starts.\n");
  5.  System.Threading.Thread.Sleep(5000);
  6.  Console.Write("The delay ends.");
  7.  return Ok(_productsService.GetAll());
  8.  }

The curl command to check response time would be:

  1. curl -i 'http://localhost:9080/api/products' -s -o /dev/null -w "Response time: %{time_starttransfer} seconds\n"

What’s next

As we learned, it is easy to configure and quick to set up API response caching for our ASP.NET Core WEB API with the help of Apache APISIX. It can reduce significantly the number of calls made to your endpoint and also improve the latency of requests to your API. There are other numerous built-in plugins available in Apache APISIX, you can check them on Plugin Hub page and use them per your need.

Recommended content

You can refer to Expose API to learn about how to expose your first API.

You can refer to Protect API to protect your API.