Download the PHP package krazydanny/laravel-repository without Composer

Laravel Model Repository

This package provides an abstraction layer for easily implementing industry-standard caching strategies with Eloquent models.

• Laravel Model Repository
  • Main Advantages
    • Simplify caching strategies and buy time
    • Save cache storage and money
  • Installation
    • Laravel version Compatibility
    • Lumen version Compatibility
    • Install the package via Composer
  • Creating a Repository for a Model
  • Use with Singleton Pattern
  • Eloquent like methods
  • Making Eloquent Queries
  • Caching methods overview
  • Implementing Caching Strategies
    • Read-Aside
    • Read-Through
    • Write-Through
    • Write-Back
  • Pretty Queries
  • Cache Invalidation Techniques
    • Saving cache storage
    • Keeping cache consistency
  • Exception handling
    • Database Exceptions
    • Cache Store Exceptions
  • Repository Events
  • Some things I wish somebody told me before
  • Bibliography

Main Advantages

Simplify caching strategies and buy time

Implementing high availability and concurrency caching strategies could be a complex and time consuming task without the appropiate abstraction layer.

Laravel Model Repository simplifies caching strategies using human-readable chained methods for your existing Eloquent models :)

Save cache storage and money

Current available methods for caching Laravel models store the entire PHP object in cache. That consumes a lot of extra storage and results in slower response times, therefore having a more expensive infrastructure.

Laravel Model Repository stores only the business specific data of your model in order to recreate exactly the same instance later (after data being loaded from cache). Saving more than 50% of cache storage and significantly reducing response times from the cache server.

Installation

Make sure you have properly configured a cache connection and driver in your Laravel/Lumen project. You can find cache configuration instructions for Laravel at https://laravel.com/docs/7.x/cache and for Lumen at https://lumen.laravel.com/docs/6.x/cache

Laravel version Compatibility

Lumen version Compatibility

Install the package via Composer

Creating a Repository for a Model

In order to simplify caching strategies we will encapsulate model access within a model repository.

Two parameters can be passed to the constructor. The first parameter (required) is the model's full class name. The second parameter (optional) is the prefix to be used in cache to store model data.

Use with Singleton Pattern

As a good practice to improve performance and keep your code simple is strongly recommended to use repositories along with the singleton pattern, avoiding the need for creating separate instances for the same repository at different project levels.

First register the singleton call in a service provider:

Add a line like this on every file you call the repository in order to keep code clean and pretty ;)

Then access the same repository instance anywhere in your project :)

You can also typehint it as a parameter in controllers, event listeners, middleware or any other service class and laravel will automatically inject the repository instance

Eloquent like methods

Calling Eloquent-like methods directly from our repository gives us the advantage of combining them with caching strategies. First, let's see how we call them. It's pretty straightforward :)

create()

Create a new model:

get()

Get a specific model by ID:

save()

Update a specific model:

delete()

Delete a specific model:

Making Eloquent Queries

Unlike get() or save(), query methods work a little different. They receive as parameter the desired query builder instance (Illuminate\Database\Eloquent\Builder) in order to execute the query.

This will allow us to combine queries with caching strategies, as we will cover forward on this document. For now let's focus on the query methods only. For example:

find()

To find all models under a certain criteria:

first()

To get the first model instance under a certain criteria:

count()

To count all model instances under a certain criteria:

Caching methods overview

remember() & during()

Calling remember() before any query method like find(), first() or count() stores the query result in cache for a given time. Always followed by the during() method, which defines the duration of the results in cache (TTL/Time-To-Live in seconds)

VERY IMPORTANT: For Laravel/Lumen v5.7 and earlier versions TTL param passed to during() are minutes instead of seconds. This library follows Laravel standards so check what unit of time your version uses for the Cache facade.

Also a model instance could be passed as parameter in order to store that specific model in cache.

according()

The according() method does almost the same as during() but with a difference, it reads the time-to-live in seconds from a given model's attribute:

This is useful if different instances of the same class have/need different or dynamic time-to-live values.

rememberForever()

Calling rememberForever() before any query method like find(), first() or count() stores the query result in cache without an expiration time.

Also a model instance could be passed as parameter in order to store that specific model in cache without expiration.

fromCache()

Calling fromCache() before any query method like find(), first() or count() will try to retrieve the results from cache ONLY.

Also a model instance could be passed as parameter in order to retrieve that specific model from cache ONLY.

forget()

This method removes one or many models (or queries) from cache. It's very useful when you have updated models in the database and need to invalidate cached model data or related query results (for example: to have real-time updated cache).

The first parameter must be an instance of the model, a specific model ID (primary key) or a query builder instance (Illuminate\Database\Eloquent\Builder).

Forget query results:

Forget a specific model using the object:

Forget a specific model by id:

The second parameter (optional) could be an array to queue forget() operations in order to be done in a single request to the cache server.

When passed the forget() method appends to the array (by reference) the removal operations instead of sending them instantly to the cache server.

It's useful when you need to expire many cached queries or models of the same repository. You can do it in one request optimizing response times for your cache server, therefore your app :)

For example:

Implementing Caching Strategies

Read-Aside Cache

How it works?

1. The app first looks the desired model or query in the cache. If the data was found in cache, we’ve cache hit. The model or query results are read and returned to the client without database workload at all.
2. If model or query results were not found in cache we have a cache miss, then data is retrieved from database.
3. Model or query results retrived from database are stored in cache in order to have a successful cache hit next time.

Use cases

Works best for heavy read workload scenarios and general purpose.

Pros

Provides balance between lowering database read workload and cache storage use.

Cons

In some cases, to keep cache up to date in real-time, you may need to implement cache invalidation using the forget() method.

Usage

When detecting you want a model or query to be remembered in cache for a certain period of time, Laravel Model Repository will automatically first try to retrieve it from cache. Otherwise will automatically retrieve it from database and store it in cache for the next time :)

Read-Aside a specific model by ID:

Read-Aside query results:

Read-Through Cache

How it works?

1. The app first looks the desired model or query in the cache. If the data was found in cache, we’ve cache hit. The model or query results are read and returned to the client without database workload at all.
2. If model or query results were not found in cache we have a cache miss, then data is retrieved from database ONLY THIS TIME in order to be always available from cache.

Use cases

Works best for heavy read workload scenarios where the same model or query is requested constantly.

Pros

Keeps database read workload at minimum because always retrieves data from cache.

Cons

If you want cache to be updated you must combine with Write-Through strategy (incrementing writes latency and workload in some cases) or implementing cache invalidation using the forget() method.

Usage

When detecting you want a model or query to be remembered in cache forever, Laravel Model Repository will automatically first try to retrieve it from cache. Otherwise will automatically retrieve it from database and store it without expiration, so it will be always available form cache :)

Read-Through a specific model by ID:

Read-Through query results:

Write-Through Cache

How it works?

Models are always stored in cache and database.

Use cases

Used in scenarios where consistency is a priority or needs to be granted.

Pros

No cache invalidation techniques required. No need for using forget() method.

Cons

Could introduce write latency in some scenarios because data is always written in cache and database.

Usage

When detecting you want a model to be remembered in cache, Laravel Model Repository will automatically store it in cache and database (inserting or updating depending on the case).

Write-Through without expiration time:

Write-Through with expiration time (TTL):

Write-Back Cache

How it works?

Models are stored only in cache until they are massively persisted in database.

Use cases

Used in heavy write load scenarios and database-cache consistency is not a priority.

Pros

Very performant and resilient to database failures and downtimes

Cons

In some cache failure scenarios data may be permanently lost.

Usage

IMPORTANT!! THIS STRATEGY IS AVAILABLE FOR REDIS CACHE STORES ONLY (at the moment)

With the buffer() or index() method Laravel Model Repository will store data in cache untill you call the persist() method which will iterate many (batch) of cached models at once, allowing us to persist them the way our project needs through a callback function.

First write models in cache:

Using buffer()

Stores models in cache in a way only accesible within the persist() method callback. Useful for optimizing performance and storage when you don't need to access them until they are persisted in database.

Using index()

Stores models in a way that they are available to be loaded from cache by get() method too. Useful when models need to be accesible before they are persisted.

Then massively persist models in database:

Using persist()

The persist() method could be called later in a separate job or scheduled task, allowing us to manage how often we need to persist models into the database depending on our project's traffic and infrastructure.

The method parameter:

It has two possible values.

• buffer (default)

Performs persist() only for those models stored in cache with the buffer() method;

• index

Performs persist() only for those models stored in cache with the index() method;

Pretty Queries

You can create human readable queries that represent your business logic in an intuititve way and ensures query criteria consistency encapsulating it's code.

For example:

Then call a pretty query :)

Cache invalidation techniques

In some cases we will need to remove models or queries from cache even if we've set an expiration time for them.

Saving cache storage

To save storage we need data to be removed from cache, so we'll use the forget() method. Remember?

For specific models:

For queries:

On events

Now let's say we want to invalidate some specific queries when creating or updating a model. We could do something like this:

Then, in the user observer...

For real-time scenarios

To keep real-time cache consistency we want model data to be updated in the cache instead of being removed.

For specific models:

We will simply use remember(), during() and rememberForever() methods:

For queries:

We would keep using forget() method as always, otherwise it would be expensive anyway getting the query from the cache, updating it somehow and then overwriting cache again.

On events

Let's assume we want to update model A in cache when model B is updated.

We could do something like this in the user observer:

Repository Events

We can also observe the following repository-level events.

• afterGet
• afterFirst
• afterFind
• afterCount

On each call

On every call

Some use cases...

• Monitoring usage of our caching strategy in production environments.
• Have a special treatment for models or query results loaded from cache than those retrieved from database.

Exceptions handling

Cache Exceptions

Database Exceptions

The silently() method

When called before any method, that operation will not throw database nor cache exceptions. Unless we've thrown them inside handleDatabaseExceptions() or handleCacheStoreExceptions() methods.

For example:

Some things I wish somebody told me before

"Be shapeless, like water my friend" (Bruce Lee)

There's no unique, best or does-it-all-right caching technique.

Every caching strategy has it's own advantages and disadvantages. Is up to you making a good analysis of what you project needs and it's priorities.

Even in the same project you may use different caching strategies for different models. For example: Is not the same caching millons of transaction logs everyday than registering a few new users in your app.

Also this library is designed to be implemented on the go. This means you can progressively apply caching techniques on specific calls.

Lets say we currently have the following line in many places of our project:

Now assume we want to implement write-back strategy for that model only in some critical places of our project and see how it goes. Then we should only replace those specifice calls with:

And leave those calls we want out of the caching strategy alone, they are not affected at all. Besides some things doesn't really need to be cached.

Be like water my friend... ;)

Bibliography

Here are some articles which talk in depth about caching strategies:

• https://bluzelle.com/blog/things-you-should-know-about-database-caching
• https://zubialevich.blogspot.com/2018/08/caching-strategies.html
• https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/
• https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/BestPractices.html