WSO2 Tutorial: Improve Cache with Redis connector

We were already talking in a previous post about WSO2 and the cache mediator, you can see it here. Today we will see an alternative but similar solution. In this case, we will use Redis, which will allow us to cache the response of a backend.

Redis is a fast and open-source in-memory key-value data structure store. Basically a key-value NoSQL database, very popular among developers. It allows the use of different data types: List, Sets, Hashes, etc.

We will be based only on the key-value pairs, the hashes. And we will see their use through an example, as always. In this example, we will call a backend and store its response associated with the object identifier. Which will allow us that when calling again with the same identifier, to return the answer previously obtained.

To begin with, we will use a WSO2 EI 6.5.0. By default, with the standalone version, it is not possible to connect to Redis. To achieve this we must do some previous steps before starting:

• Add the Jedis library (2.10.2) in the ${WSO2_HOME}/lib folder
• Start the server.
• Add the Redis connector through the graphical interface. The connector can be obtained from the WSO2 Store, and there are different versions depending on the product we use.
• It is necessary to enable the connector manually before we can use it.

The easiest way to use Redis is as always to use docker, and for this, we will use the following command:

docker run -p 6379:6379 --name redis -d redis

The use of the Redis connector is similar to other connectors. Basically, they are custom mediators, which support multiple properties and which have names that identify the operations they perform.

We are going to create an API with several resources. In the first resource we will perform the following steps:

• We look for the identifier in Redis through the hExists operation. In which we have to include the volume where it is stored and its key.
• If the key exists, we will use the hGet operation with the same values to retrieve the stored value.
• If the key does not exist, we will proceed to call the backend. Then we will store the value through the hSet operation, in which we will indicate the volume, the key, and the associated value.

We must also take into account different aspects of the connector:

• The first time we use the connector we must invoke the init operation, which will enable us to connect to Redis.
• The result of the hExists operation is stored in a context property called redisResponse.
• The hExists operation returns a true or false value based on whether or not it finds the result.
• We must store and restore the payload when using the hSet operation to avoid returning the result of the operation to the client.

This approach has two significant improvements:

• Unlike the cache mediator, with the Redis connector, we can delete a stored value. And this is thanks to the fact that the connector contains multiple operations.
• Unlike the cache mediator, it’s not attached to the payload. So we can use it with HTTP GET method without a problem. And associated with a generated key develop by us.

This is a very basic example, in our integration. But we can make different calls, add more complicated logic and then store that value based on an identifier. This can lead us to greatly improve the performance of our integrations.

Before finish, we are going to see a comparison about how works an API without cache and another with Redis cache. Where we can see that it’s clearly better to use Redis. For the comparison we use hey which we can launch 1000 requests and show us a very good report of them.

On the left, we can see how it works without cache, and on the right the execution of the above example.