Download the PHP package matchory/response-cache without Composer

On this page you can find all versions of the php package matchory/response-cache. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package response-cache

Response Cache Latest Stable Version Total Downloads Latest Unstable Version License Laravel Octane Compatible

A Laravel package that adds a smart cache for full responses

Using this package, you can cache full response instances returned from your controllers, simply by adding a middleware.
This can speed up your application immensely!

Features

Alternatives

Coincidentally, I just learned spatie have built almost exactly the same library as we did:
spatie/laravel-responsecache.

Why not use Varnish?

In contrast to external caches, having the response cache in your app gives you the power to evaluate route bindings, authentication state, and easy programmatic cache flushing.
This also makes it possible to place the cache check anywhere in your middleware stack!

Requirements

Installation

Install using composer:

Unless you have disabled package discovery, everything should be set up already. Otherwise, add the service provider and the facade to your configuration.

Optionally, you can publish the configuration file:

Check out the configuration section to learn about all available options.

Add the middleware to your app/Http/Kernel.php:

Configuration

The config file contains the following settings:

enabled (Environment variable: RESPONSE_CACHE_ENABLED)

Using this setting, you can globally enable or disable the response cache for all requests. If you set it to false, nothing will be cached.

Defaults to true.

ttl (Environment variable: RESPONSE_CACHE_TTL)

This setting specifies the amount of time responses will be cached before being marked as stale. The value must be specified in seconds.

Defaults to 60 * 60 * 24, or exactly 24 hours.

store (Environment variable: RESPONSE_CACHE_STORE)

Here you may pass any cache store defined in your config/cache.php file. Please note that not all stores support tagging: For better control over and increased performance of your cache, we strongly recommend using a store with tag support, like Redis or APC.

Defaults to file.

tags (Environment variable: RESPONSE_CACHE_TAGS)

If your store supports tags, all responses cached will also be tagged with these tags by default. Additional tags may be used depending on the middleware and strategy.

Defaults to [].

server_timing (Environment variable: RESPONSE_CACHE_SERVER_TIMING)

If the server timing option is enabled, a Server-Timing header containing the initial caching time will be added to all cached responses. This makes debugging easier. Leaving it enabled in production probably has no negative consequences aside from a small performance penalty due to the bigger response size.

Defaults to false.

Usage

After following the installation instructions above, you should be ready to go: Responses with a status code in the 200 and 300 range will be cached and returned on subsequent visits. To bypass the cache for specific routes, you can simply add the bypass_cache middleware:

Flushing the cache manually

To clear the cache manually, you can use the response-cache:flush artisan command:

This will flush the entire response cache. To delete a given set of cache tags only, add them to the command:

Flushing the cache programmatically

In production use, it is often helpful to flush the cache automatically if something happens. For example, you can flush the cache whenever a model event is fired by setting up an observer:

By invoking the clear method, the entire store (for the given tags) will be purged. To be more selective, use the delete method:

Note: This will not work for cache items that require context information, such as user authentication. If you hit this problem, you'll probably want to work with tags instead.

Cache Tags

Cache tags are a simple, yet very powerful mechanism for efficient cache usage. By applying tags to a set of cached items, you can purge all of them, without ever knowing the individual cache keys of these items. Say, there are lots of cached data points all related to "flights": plane schedules, arrival dates, passenger records, etc. All is fine and well, until a flight is cancelled! Now, we will need to purge the cache for anything that includes the flight in question. This would be a logical nightmare, hadn't we set up cache tags: Instead of deleting lots of items manually, we instruct Laravel to purge all items tagged with the flight number, and we're good to go!

This library is built heavily around the concept of cache tags: By tagging properly, you can make granular cache flushing a breeze. Tags can be added to routes using several approaches:

Using bindings in cache tags

This library supports adding dynamic tags that are based on route bindings. This works pretty much the same as with ordinary route bindings, but with the added benefit of also having access to all request values, not just those mentioned in the route itself.
To add a binding to your cache tag, simply include the name of a parameter in curly braces: flights.{flight}. As soon as something is to be fetched from or put into the cache, this binding will be resolved using the current request instance. If the parameter flight was an instance of an Eloquent model, it would be replaced with its route key name, so probably the flight ID!

Take a look at the following example:

Imagine we perform the following request: /api/v3/flights/505
Now, the response generated by this route would be tagged with the following tags:

Depending on your requirements, you can simply flush the cache for any of these and rest assured the response will be invalidated!

Caching Strategies

A strategy is what the response cache uses to determine just how a response should be cached. It generates cache keys, determines cache tags and controls cache bypassing. The default strategy should fit for most use cases, but if it doesn't, we got you covered, too!

To use a custom strategy, start by either extending the default implementation (recommended) or implementing the CacheStrategy interface.

Customize cache keys

To customize the way cache keys are generated, you have several options, as the default implementation splits this process in multiple methods:

Customizing cache bypass

To customize whether a response is cached or not, you can implement one or more helpers:

By default, this will cache any request with the GET or HEAD methods, and responses with a success or redirection status.

Customizing tagging

Tagging cached responses is an immensely powerful feature that allows you to flush a collection of cache entries if something happens. So if a single member of a collection is deleted, for example, you can remove all cached instances of the same collection, without having to know the exact cache keys used to retrieve them!
To make this as easy as possible, strategies provide a method to pull tags from a request and response:

Using the ResponseCache middleware manually

Instead of simply adding the caching middleware to all web routes as shown above, you can of course also add it to selected routes manually. In this case, you also have the possibility to configure the time to leave and add a set of tags per route:

If the first parameter to the middleware is a number, it will be interpreted as a TTL value, everything that follows as tags. The TTL will override the configuration value, tags will be merged.

Reacting to cache events

This library exposes some events you can listen for and act accordingly. This is probably most helpful during debugging.

Hit

Emitted if a response was found in the cache. Includes the request instance.

Miss

Emitted if a response could not be found in the cache or was indicated as non-cachable by the caching strategy and thus had to be generated by the application. Includes the request instance.

Flush

Emitted if the cache was flushed. Includes the tags that were flushed, or null if all tags were flushed.

Manual response serialization

By default, the response cache uses a cache repository implementation with a very simple serialization method: Doing nothing. Any serialization is deferred to Laravel's cache implementation. In rare cases, you may need to change this behavior and modify a response before serializing or after hydrating it.
To do so, start by extending the Repository class:

Override the container binding in your AppServiceProvider, so your repository will be used instead of the default:

Debugging

Cache issues can be a little annoying to debug. This library has several facilities built in to make the process as simple as possible:

  1. Enable the Server-Timing header: By switching this feature on, all responses will include a Server-Timing header that includes the time your response was cached. This information will automatically show up in your browser's developer tools!
  2. Listen to cache events: By listening to the cache events, you can make sure everything is working as intended.
  3. Temporarily or conditionally disable caching: By changing the response-cache.enabled setting, you can quickly determine whether caching is the culprit.
  4. Use a custom repository: Override the built-in serialization method to take control of response serialization and hydration.

All versions of response-cache with dependencies

PHP Build Version
Package Version
Requires php Version >=8.2
illuminate/support Version ^v10.48|^11.11
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package matchory/response-cache contains the following files

Loading the files please wait ....