184 lines
9.0 KiB
Markdown
184 lines
9.0 KiB
Markdown
## Caching
|
|
|
|
### Standard Caching
|
|
|
|
Object descriptions that are requested through the ObjectRetriever are fetched through the CloudObjects Core Object API. They are cached in-memory inside the class for a default of 60 seconds. This can be changed using the `cache_ttl` option, which takes a number of seconds.
|
|
|
|
```php
|
|
use CloudObjects\SDK\ObjectRetriever;
|
|
|
|
// Keep objects in memory for 5 minutes
|
|
$retriever = new ObjectRetriever([
|
|
'cache_ttl' => 300,
|
|
]);
|
|
```
|
|
|
|
This in-class memory obviously only works as long as the class is alive and prevents subsequent requests for the same object hitting the API, but the cache will not exist between multiple requests handled in different processes. For this purpose, an external cache should be added.
|
|
|
|
To add an external cache, provide a storage using the `cache_storage` interface. The storage must be a class that implements either of the following interfaces:
|
|
|
|
- `Kevinrob\GuzzleCache\Storage\CacheStorageInterface`
|
|
- `Psr\Cache\CacheItemPoolInterface`
|
|
- `Psr\SimpleCache\CacheInterface`
|
|
|
|
External storage is used twice:
|
|
|
|
- Storing the HTTP request according to the APIs caching headers.
|
|
- Storing the object data according to `cache_ttl`.
|
|
|
|
All keys written to the external cache are prefixed with the value of the `cache_prefix` option (default: `clobj:`), so you can share a cache with other parts of your application.
|
|
|
|
The following examples use the [Symfony Cache component](https://symfony.com/doc/current/components/cache.html), but any library implementing one of the interfaces above works.
|
|
|
|
Using a PSR-6 cache pool, e.g. on the filesystem:
|
|
|
|
```php
|
|
use CloudObjects\SDK\ObjectRetriever;
|
|
use Symfony\Component\Cache\Adapter\FilesystemAdapter;
|
|
|
|
$retriever = new ObjectRetriever([
|
|
'cache_storage' => new FilesystemAdapter('cloudobjects', 0, '/var/cache/myapp'),
|
|
'cache_ttl' => 300,
|
|
]);
|
|
```
|
|
|
|
Using a PSR-16 simple cache, e.g. in Redis:
|
|
|
|
```php
|
|
use CloudObjects\SDK\ObjectRetriever;
|
|
use Symfony\Component\Cache\Adapter\RedisAdapter;
|
|
use Symfony\Component\Cache\Psr16Cache;
|
|
|
|
$redis = RedisAdapter::createConnection('redis://localhost');
|
|
|
|
$retriever = new ObjectRetriever([
|
|
'cache_storage' => new Psr16Cache(new RedisAdapter($redis)),
|
|
'cache_prefix' => 'myapp:clobj:',
|
|
]);
|
|
```
|
|
|
|
### Fallback Store
|
|
|
|
Fallback store is a mechanism that can be used by applications that require high availability but may lose connectivity to CloudObjects Core. With fallback store, a copy of an object is saved in a directory. If the API fails with a 5xx error, times out, or the request fails without a response, an `ObjectRetriever` will return the stored copy instead. Be advised that fallback storage will, once configured, result in your application not noticing when the Object API is unreachable - at least for objects in the store - and will continue to deliver the saved copy even if the original in CloudObjects Core is changed or removed.
|
|
|
|
It is possible for the fallback store to be configured for all objects or only for objects in specified namespaces. Since the SDK updates stored copies whenever it retrieves an object successfully but never deletes them, not even when the object has been removed from CloudObjects Core, the fallback store can grow large; hence it should be limited to specific namespaces in applications where many random objects may be retrieved. **Use this feature with caution and disable it if it causes any problems.**
|
|
|
|
To enable fallback store, set the `fallback_store_directory` option to a writeable path on the filesystem. Also, set `fallback_store_scope` to either the string `*` to save all retrieved objects, or a list of namespaces (domains only without `coid://` prefix); the list of namespaces can be provided as a comma-separated string or an array of strings.
|
|
|
|
Storing all retrieved objects:
|
|
|
|
```php
|
|
use CloudObjects\SDK\ObjectRetriever;
|
|
|
|
$retriever = new ObjectRetriever([
|
|
'fallback_store_directory' => '/var/lib/myapp/cloudobjects-fallback',
|
|
'fallback_store_scope' => '*',
|
|
]);
|
|
```
|
|
|
|
Storing only objects from specific namespaces, provided as an array:
|
|
|
|
```php
|
|
use CloudObjects\SDK\ObjectRetriever;
|
|
|
|
$retriever = new ObjectRetriever([
|
|
'fallback_store_directory' => '/var/lib/myapp/cloudobjects-fallback',
|
|
'fallback_store_scope' => [ 'example.com', 'cloudobjects.io' ],
|
|
]);
|
|
```
|
|
|
|
Or as a comma-separated string, which is convenient when the value comes from an environment variable:
|
|
|
|
```php
|
|
use CloudObjects\SDK\ObjectRetriever;
|
|
|
|
$retriever = new ObjectRetriever([
|
|
'fallback_store_directory' => getenv('FALLBACK_STORE_DIRECTORY'),
|
|
'fallback_store_scope' => 'example.com,cloudobjects.io',
|
|
]);
|
|
```
|
|
|
|
The fallback store can be combined with an external cache. The cache is still consulted first; the fallback store only comes into play when an object is neither cached nor retrievable from the API.
|
|
|
|
```php
|
|
use CloudObjects\SDK\ObjectRetriever;
|
|
use Symfony\Component\Cache\Adapter\FilesystemAdapter;
|
|
|
|
$retriever = new ObjectRetriever([
|
|
'cache_storage' => new FilesystemAdapter('cloudobjects', 0, '/var/cache/myapp'),
|
|
'cache_ttl' => 300,
|
|
'fallback_store_directory' => '/var/lib/myapp/cloudobjects-fallback',
|
|
'fallback_store_scope' => 'example.com',
|
|
]);
|
|
```
|
|
|
|
### Permanent Store
|
|
|
|
Permanent store is a mechanism that can be used by applications that want to minimize connections to CloudObjects Core, may go offline after initialization, or want to work with the same version of an object for the lifetime of their run without getting updates. With permanent store, an `ObjectRetriever` saves a copy of an object in a directory the first time it retrieves it from the Object API. Once an object is in the permanent store, the API will _never_ be contacted for this object again. Be advised that permanent storage will, once configured, result in your application continuing to deliver the saved copy even if the original in CloudObjects Core is changed or removed, and not noticing when the Object API is unreachable - at least for objects in the store.
|
|
|
|
It is possible for the permanent store to be configured for all objects or only for objects in specified namespaces. Since the permanent store is never purged or refreshed by the SDK, it can grow large; hence it should be limited to specific namespaces in applications where many random objects may be retrieved. To get the latest version of an object, delete its copy from the directory, or clear the directory entirely. **Use this feature with caution and disable it if it causes any problems.**
|
|
|
|
To enable permanent store, set the `permanent_store_directory` option to a writeable path on the filesystem. Also, set `permanent_store_scope` to either the string `*` to save all retrieved objects, or a list of namespaces (domains only without `coid://` prefix); the list of namespaces can be provided as a comma-separated string or an array of strings.
|
|
|
|
Storing all retrieved objects:
|
|
|
|
```php
|
|
use CloudObjects\SDK\ObjectRetriever;
|
|
|
|
$retriever = new ObjectRetriever([
|
|
'permanent_store_directory' => '/var/lib/myapp/cloudobjects-permanent',
|
|
'permanent_store_scope' => '*',
|
|
]);
|
|
```
|
|
|
|
Storing only objects from specific namespaces, provided as an array:
|
|
|
|
```php
|
|
use CloudObjects\SDK\ObjectRetriever;
|
|
|
|
$retriever = new ObjectRetriever([
|
|
'permanent_store_directory' => '/var/lib/myapp/cloudobjects-permanent',
|
|
'permanent_store_scope' => [ 'example.com', 'cloudobjects.io' ],
|
|
]);
|
|
```
|
|
|
|
Or as a comma-separated string, which is convenient when the value comes from an environment variable:
|
|
|
|
```php
|
|
use CloudObjects\SDK\ObjectRetriever;
|
|
|
|
$retriever = new ObjectRetriever([
|
|
'permanent_store_directory' => getenv('PERMANENT_STORE_DIRECTORY'),
|
|
'permanent_store_scope' => 'example.com,cloudobjects.io',
|
|
]);
|
|
```
|
|
|
|
The permanent store can be combined with an external cache. The cache is still consulted first, as it may be faster than the filesystem; the permanent store only comes into play when an object is not cached, and the API is only contacted when the object is in neither.
|
|
|
|
```php
|
|
use CloudObjects\SDK\ObjectRetriever;
|
|
use Symfony\Component\Cache\Adapter\FilesystemAdapter;
|
|
|
|
$retriever = new ObjectRetriever([
|
|
'cache_storage' => new FilesystemAdapter('cloudobjects', 0, '/var/cache/myapp'),
|
|
'cache_ttl' => 300,
|
|
'permanent_store_directory' => '/var/lib/myapp/cloudobjects-permanent',
|
|
'permanent_store_scope' => 'example.com',
|
|
]);
|
|
```
|
|
|
|
Permanent store and fallback store can be combined, for example to pin objects from your own namespace while keeping a fallback copy of everything else. Both stores must use separate directories, otherwise the `ObjectRetriever` throws an `InvalidSDKConfigurationException`. If an object is in scope of both, the permanent store takes precedence.
|
|
|
|
```php
|
|
use CloudObjects\SDK\ObjectRetriever;
|
|
|
|
$retriever = new ObjectRetriever([
|
|
'permanent_store_directory' => '/var/lib/myapp/cloudobjects-permanent',
|
|
'permanent_store_scope' => 'example.com',
|
|
'fallback_store_directory' => '/var/lib/myapp/cloudobjects-fallback',
|
|
'fallback_store_scope' => '*',
|
|
]);
|
|
```
|
|
|
|
Unlike `static_config_path`, which reads object descriptions that you provide yourself, the permanent store is filled automatically by the SDK from the Object API.
|