DevoteamInsightsBlog Series, Part III: Applying caching API Policy Caching in CloudHub

Blog Series, Part III: Applying caching API Policy Caching in CloudHub

Author

Johnny Madrid
MuleSoft Lead Developer

This is the final post of this series and we will understand the mechanism of storing data on the server-side using an out of box feature of API Policy in Cloudhub.

Applying API Policy Caching in CloudHub

In my previous post, I demonstrated the step-by-step guide on how to implement caching inside a Mule4 project. I will demonstrate a second approach on how to achieve the same end result but using a better, more innovative way from CloudHub meaning you don’t need to implement it from inside your Mule4 project.

The following steps are applicable once your application is deployed in the environment you selected. Ensure you have permission to apply ‘Policies’.

Go to API Manager, select your application on API Administration, and click on your application.

In the Policies section, click on Apply New Policy

It will display a window with all categories applicable to your application.

Configure with the following mandatory fields:

Field	Value
HTTP Caching Key	#[attributes.requestPath]
Maximum Cache Entries	10000
Entry Time To Live (in seconds)	600
Persistent Cache	True
Conditional Request Caching Expression	#[attributes.method == ‘GET’ or attributes.method == ‘HEAD’]
Conditional Response Caching Expression	#[[200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501] contains attributes.statusCode]

Method & Resource conditions:

Apply configurations to all API methods & resources

Confirm and verify all configurations as image below

Applying and enforcing the API Policy will need to redeploy the application.

As a result, logs will reflect the following:

Testing HTTP Caching policy

Use curl to send a request and obtain a verbose response

Verify Object Store at application

As a result, the HTTP request path is used to check against policy resource matching.

Testing second time Caching Policy

New keys on Object Store

Re-testing first request.

Pay special attention to the ‘age’ header. (In seconds)

Once TTL is reached, Object Store is updated

Extra Considerations

Distributed cache:

Enables the underlying cache to be distributed. Select this option if the deployment target is a cluster or multiple cloudhub workers. To use distributed caching in Cloudhub the objectStoreV2 checkbox must be checked in runtime manager application properties.

Persistent cache:

Indicates if the cache will be persistent across runtime restart. To use persistent caching in Cloudhub the objectStoreV2 checkbox must be checked in runtime manager application properties.

HTTP Caching Directives

Enables the usage of Cache-Control header directives. Supported headers are “Cache-Control” with supported values: max-age=<seconds>, s-maxage=<seconds>, no-cache and no-store; and “Expires” whose value is <date in RFC 1123 format> (E.g. “Mon, 25 June 2018 19:29:52 GMT”). It supports comma-separated multiple values.

Conditional Request Caching Expression

Only the requests for which this expression is true will interact with the cache. This field is a dataweave expression. For further information on additional variables available check the documentation cited in the HTTP Caching key description.

#[attributes.method == ‘GET’ or attributes.method == ‘HEAD’]

Conditional Response Caching Expression

Only the responses for which this expression is true will be stored in the cache. This field is a dataweave expression. For further information on additional variables available check the documentation cited in the HTTP Caching key description.

#[[200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501] contains attributes.statusCode]

Configuring Policy Parameters

Summary of configuration available in API Manager.

Parameter	Description	Default	Required
HTTP Caching Key	Dataweave expression.	#[attributes.requestPath]	Yes
Maximum Cache Entries	A maximum number of entries that can be stored in the cache at any given time.	10000	Yes
Entry Time To Live	Amount of time (seconds) after which the entry expires from the cache	600	Yes
Distributed	To be distributed among different nodes in a cluster.	false	Yes
Persistent Cache	To persist between different restarts of the mule instance.	false	Yes
Follow HTTP Caching directives	Use of Cache-Control header directives	true	Yes
Conditional Request Caching Expression	Dataweave expression to determine which requests are cached.#[attributes.method == ‘GET’ or attributes.method == ‘HEAD’]	–	No
Conditional Response Caching Expression	Dataweave expression to determine which responses are cached.#[[200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501] contains attributes.statusCode]	–	No