Version 3.1 and 3.2 of the TypeDCMS Starter Kit for Laravel have been released

This Starter Kit has always included an out-of-the-box caching strategy that is suitable for most applications. However, it is not always the best fit for every application. With this release, we now have flush, eager and async caching strategies, enabling you to choose the one that best fits your application.

In This Release

The Invalidation Strategy Is Now Configurable

For most applications the flush strategy is sufficient. It works by clearing cached data related to the field, construct, or blueprint that has been updated. When the cache is cleared, the next request will fetch fresh data from the API and cache it again.

If performance is a concern, the eager strategy can be used. This strategy will queue a job to fetch fresh data from the API and cache it immediately after an update. The downside of this strategy is that it will make an additional API requests between sequential changes. However, this strategy ensures that the cache is always up-to-date and can be useful in applications where data changes frequently.

The async strategy is similar to the eager strategy, but it will queue a job to fetch fresh data from the API and cache it after a request has been completed. This strategy is useful in applications where performance is a concern, but data accuracy is less critical. Under this strategy, the cache may be stale for a short period of time after an update, but it will eventually be updated in the background.

Low Impact Changes

New Configuration Option for Caching Strategy

There are now a number of additional configuration options for caching:

<?php

//...

return [
    //...

    /*
     |---------------------------------------------------------------------------
     | Repository Cache Clearing Strategy
     |---------------------------------------------------------------------------
     |
     | Three cache clearing strategies are supported by this starter kit:
     |
     |  - flush: When the `clear-cache` webhook is received, cached results from
     |           affected repositories are simply invalidated.
     |
     |  - eager: When the `cache-clear` webhook is received, a job is queued to
     |           fetch fresh data for affected repositories.
     |
     |  - async: When the `cache-clear` webhook is received, cached results from
     |           affected repositories are flagged for invalidation. When the
     |           data is next requested, a job is queued to fetch the fresh
     |           data.
     |
     */
    'cache_strategy' => env('CACHE_STRATEGY', 'flush'),

    /*
     |---------------------------------------------------------------------------
     | Repository Cache Expiration
     |---------------------------------------------------------------------------
     |
     | Cached repository data will be automatically invalidated after the given
     | seconds, or never if set to null.
     |
     */
    'cache_expiration' => null,

    /*
     |---------------------------------------------------------------------------
     | Granular Cache Refresh Queueing
     |---------------------------------------------------------------------------
     |
     | When enabled, each refresh call is broken into a separate queued job.
     | This can be used to allow many refresh jobs to take place simultaneously.
     |
     */
    'granular_cache_queueing' => false,

    //...
];