Oliver Davies
7a7dc297ca
Now the abs_to_rel module is enabled, links can be made relative so they work on the current environment.
100 lines
No EOL
6.2 KiB
JSON
100 lines
No EOL
6.2 KiB
JSON
{
|
|
"uuid": [
|
|
{
|
|
"value": "1550e619-abd2-4efe-b941-fd4e42507d51"
|
|
}
|
|
],
|
|
"langcode": [
|
|
{
|
|
"value": "en"
|
|
}
|
|
],
|
|
"type": [
|
|
{
|
|
"target_id": "daily_email",
|
|
"target_type": "node_type",
|
|
"target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
|
|
}
|
|
],
|
|
"revision_timestamp": [
|
|
{
|
|
"value": "2025-05-11T08:59:58+00:00"
|
|
}
|
|
],
|
|
"revision_uid": [
|
|
{
|
|
"target_type": "user",
|
|
"target_uuid": "b8966985-d4b2-42a7-a319-2e94ccfbb849"
|
|
}
|
|
],
|
|
"revision_log": [],
|
|
"status": [
|
|
{
|
|
"value": true
|
|
}
|
|
],
|
|
"uid": [
|
|
{
|
|
"target_type": "user",
|
|
"target_uuid": "b8966985-d4b2-42a7-a319-2e94ccfbb849"
|
|
}
|
|
],
|
|
"title": [
|
|
{
|
|
"value": "Caching with decorators"
|
|
}
|
|
],
|
|
"created": [
|
|
{
|
|
"value": "2025-04-06T00:00:00+00:00"
|
|
}
|
|
],
|
|
"changed": [
|
|
{
|
|
"value": "2025-05-11T08:59:58+00:00"
|
|
}
|
|
],
|
|
"promote": [
|
|
{
|
|
"value": false
|
|
}
|
|
],
|
|
"sticky": [
|
|
{
|
|
"value": false
|
|
}
|
|
],
|
|
"default_langcode": [
|
|
{
|
|
"value": true
|
|
}
|
|
],
|
|
"revision_translation_affected": [
|
|
{
|
|
"value": true
|
|
}
|
|
],
|
|
"path": [
|
|
{
|
|
"alias": "\/daily\/2025\/04\/06\/caching",
|
|
"langcode": "en"
|
|
}
|
|
],
|
|
"body": [
|
|
{
|
|
"value": "\n <p>As well as <a href=\"/daily\/2025\/04\/05\/strategies\">working with different versions of an API<\/a>, I was able to use the same technique I wrote about yesterday to easily add a cacheable version of the API client.<\/p>\n\n<p>As they all implement the same <code>ApiClientInterface<\/code>, I can inject and decorate a client with another client, making one solely responsible for caching the result from the API whilst keeping the API interaction logic separate (aka <a href=\"/daily\/2022\/12\/08\/the-decorator-design-pattern\">the Decorator design pattern<\/a>).<\/p>\n\n<p>Here's an example based on the code I wrote:<\/p>\n\n<pre><code class=\"php\">final class CacheableApiClient implements ApiClientInterface {\n\n \/**\n * The cache duration in seconds.\n *\/\n private const CACHE_DURATION = 3600;\n\n public function __construct(\n private readonly ApiClientInterface $client,\n private readonly TimeInterface $time,\n private readonly CacheBackendInterface $cache,\n ) {\n }\n\n public function getResults(): Collection {\n $key = $this->getCacheKey();\n\n $cache = $this->cache->get($key);\n\n if ($cache !== FALSE) {\n return $cache->data;\n }\n\n $result = $this->client->getResults();\n\n $this->cache->set(\n cid: $key,\n data: $result,\n expire: $this->time->getRequestTime() + self::CACHE_DURATION,\n );\n\n return $result;\n }\n\n}\n<\/code><\/pre>\n\n<p>Nothing in this instance is specific to either version of the API.<\/p>\n\n<p>This client is only concerned with retrieving and saving cache data, and delegating any other logic to the original version.<\/p>\n\n<p>With this approach, I can switch between <code>V1ApiClient<\/code>, <code>V2ApiClient<\/code> or any other version with the same methods without having to reimplement caching as that's handled within the <code>CacheableApiClient<\/code>.<\/p>\n\n<p>But what if I don't want to interact with the API at all?<\/p>\n\n<p>For local development, I have a <code>FakeApiClient<\/code> that returns a static response that I can work with.<\/p>\n\n<p>The possibilities are endless.<\/p>\n\n ",
|
|
"format": "full_html",
|
|
"processed": "\n <p>As well as <a href=\"/daily\/2025\/04\/05\/strategies\">working with different versions of an API<\/a>, I was able to use the same technique I wrote about yesterday to easily add a cacheable version of the API client.<\/p>\n\n<p>As they all implement the same <code>ApiClientInterface<\/code>, I can inject and decorate a client with another client, making one solely responsible for caching the result from the API whilst keeping the API interaction logic separate (aka <a href=\"/daily\/2022\/12\/08\/the-decorator-design-pattern\">the Decorator design pattern<\/a>).<\/p>\n\n<p>Here's an example based on the code I wrote:<\/p>\n\n<pre><code class=\"php\">final class CacheableApiClient implements ApiClientInterface {\n\n \/**\n * The cache duration in seconds.\n *\/\n private const CACHE_DURATION = 3600;\n\n public function __construct(\n private readonly ApiClientInterface $client,\n private readonly TimeInterface $time,\n private readonly CacheBackendInterface $cache,\n ) {\n }\n\n public function getResults(): Collection {\n $key = $this->getCacheKey();\n\n $cache = $this->cache->get($key);\n\n if ($cache !== FALSE) {\n return $cache->data;\n }\n\n $result = $this->client->getResults();\n\n $this->cache->set(\n cid: $key,\n data: $result,\n expire: $this->time->getRequestTime() + self::CACHE_DURATION,\n );\n\n return $result;\n }\n\n}\n<\/code><\/pre>\n\n<p>Nothing in this instance is specific to either version of the API.<\/p>\n\n<p>This client is only concerned with retrieving and saving cache data, and delegating any other logic to the original version.<\/p>\n\n<p>With this approach, I can switch between <code>V1ApiClient<\/code>, <code>V2ApiClient<\/code> or any other version with the same methods without having to reimplement caching as that's handled within the <code>CacheableApiClient<\/code>.<\/p>\n\n<p>But what if I don't want to interact with the API at all?<\/p>\n\n<p>For local development, I have a <code>FakeApiClient<\/code> that returns a static response that I can work with.<\/p>\n\n<p>The possibilities are endless.<\/p>\n\n ",
|
|
"summary": null
|
|
}
|
|
],
|
|
"feeds_item": [
|
|
{
|
|
"imported": "1970-01-01T00:33:45+00:00",
|
|
"guid": null,
|
|
"hash": "dd52b641b6c5a3e8eb19c47343f766c3",
|
|
"target_type": "feeds_feed",
|
|
"target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
|
|
}
|
|
]
|
|
} |