Blueprint projects
- Frontend
- Blueprint assignments
- Blueprint builders
- Blueprint general
- Blueprint how to
- Blueprint tools
- Backend
Response Cache
Introduction
Some data retrieval or processing tasks performed by the application could be CPU intensive or take several seconds to complete. When this is the case, it is common to cache the retrieved data for a time, so it can be retrieved quickly for the same data.
This type of caching caches the entire response of the given successful get-requests that return text based content (such as html and json) for a month. It speeds up the response quite considerably. So the first time a request comes will save the response before sending it to the users. When the same request comes in again we’re not going through the entire application but just respond with the saved response.
Response Cache is based on Laravel Cache feature and Spatie’s Response Cache package.
Configuration
The cached responses use cache tags and are stored in the Redis data store to make tagging possible. That’s why to have it up and running properly make sure to have the following env. variables defined correctly in the .env file(s).
CACHE_DRIVER=redis
RESPONSE_CACHE_DRIVER=redis
RESPONSE_CACHE_ENABLED=true
To be able to use the route middleware, make sure it’s defined in project’s Infrastructure\Http\Kernel.php file:
protected $routeMiddleware = [
'cacheResponse' => \Spatie\ResponseCache\Middlewares\CacheResponse::class,
];
Usage
If configured, it already caches all the Blueprint index and list requests of:
- modules
- roles
- permissions
- base-data
- locales
- translations
- settings
Storing Responses In The Cache
To have the wanted set of requests to be response cached just wrap the wanted routes in the cacheResponse route middleware.
Route::middleware(['cacheResponse'])->group(function () {
Route::get('example-action', [ExampleController::class, 'action']);
});
By default, the responses get cached for one month, but you can specify the number of seconds the routes should be cached:
Route::middleware(['cacheResponse:300'])->group(function () {
Route::get('example-action', [ExampleController::class, 'action']);
});
To use cache tags, you can specify a list of tags when applying the middleware.
Route::middleware(['cacheResponse:foo,bar'])->group(function () {
Route::get('example-action', [ExampleController::class, 'action']);
});
Route::middleware(['cacheResponse:something'])->group(function () {
Route::get('another-example-action', [ExampleController::class, 'anotherAction']);
});
Removing Responses From The Cache
To make sure that responses get cleared on model changes, use the provided trait on the wanted model class. For example this statement would remove both example-action and another-example-action routes above:
use Capturum\Blueprint\Application\Traits\FlushCacheTrait;
class Example extends Model
{
use FlushCacheTrait;
protected array $responseCacheTags = [
'foo',
'something',
];
}
There are several ways to clear the response cache by issuing artisan commands, here are 2 options:
php artisan responsecache:clear
This clears ALL the redis cache if you have not specified 'cache_tag' => 'responsecache' (or some other tag name) in your responsecache.php config file. If you have, then it clears only the responsecache cache.
Or,
php artisan blueprint:flush-cache-tag --tag=<response-cache-tag-1> --tag=<response-cache-tag-2>
This clears a tagged cache store and is not restricted to the response cache.
Extending
There are a set of contracts provided to extend the way Response Cache is working:
CorsHeaderReplacerContract
Here you may redefine replacers that dynamically replace content from the response.
ResponseCacheHasherContract
This class is responsible for generating a hash for a request. This hash is used as a key to look up a cached response.
By default, it takes into account the current:
- host
- URI
- method
- tenant id
- locale id