Mule 4 Custom HTTP Radis Cache Policy

Introduction

The HTTP Custom Caching policy enables you to store HTTP responses from an API implementation or an API proxy for reuse. To optimize against computation-heavy processing, this policy avoids performing multiple calls to the backend when the response of a service does not change often. This policy uses a cache, which enables a faster service for data requests.

In Mule 4, Mulesoft already provides an HTTP cache policy, which is available out of the box with standard configuration and works very well with runtime object-store v2. If an existing out-of-the-box policy is available then why do we need a custom policy?

1. This means your runtime application needs to be deployed on cloudhub; runtime applications deployed on a customer-hosted runtime can’t use this in the built-in policy.
2. It works with the standard configuration; if you need a custom configuration or expression to be used to pick up the key, then it is not possible with the out-of-the-box policy.

In this custom cache policy, the cache is backed by Redis storage which is an open-source (BSD licensed), in-memory data structure store, used as a database, cache, and message broker. In this example, we are using an Upstash service provider for Redis, as they provide on cloud Redis and only take 5 minutes to get a new Redis instance (via the trial version).

This custom cache policy flow is shown below:

Create a trial Redis server for us on Upstash. It takes 5 minutes to get a Redis database and can do testing using Redis-CLI.

Additional Resources

• Getting started
• Code repo 
• How to develop a Mule 4 custom policy