shopify / response_bank

Simple response caching for Ruby applications

ResponseBank

Features

• Serve gzip'd content
• Add ETag and 304 Not Modified headers
• Generational caching
• No explicit expiry

Support

This gem supports the following versions of Ruby and Rails:

• Ruby 2.7.0+
• Rails 6.0.0+

Usage

1. include the gem in your Gemfile

   gem 'response_bank'

2. add an initializer file. We need to configure the acquire_lock method, set the cache store and the logger

   require 'response_bank'
   
   module ResponseBank
     LOCK_TTL = 90
   
     class << self
       def acquire_lock(cache_key)
         cache_store.write("#{cache_key}:lock", '1', unless_exist: true, expires_in: LOCK_TTL, raw: true)
       end
     end
   end
   
   ResponseBank.cache_store = ActiveSupport::Cache.lookup_store(Rails.configuration.cache_store)
   ResponseBank.logger = Rails.logger

3. enables caching on your application

   config.action_controller.perform_caching = true

4. use #response_cache method to any desired controller's action

   class PostsController < ApplicationController
     def show
       response_cache do
         @post = @shop.posts.find(params[:id])
         respond_with(@post)
       end
     end
   end

5. (optional) set a custom TTL for the cache by overriding the write_to_backing_cache_store method in your initializer file

   module ResponseBank
     CACHE_TTL = 30.minutes
     def write_to_backing_cache_store(_env, key, payload, expires_in: nil)
       cache_store.write(key, payload, raw: true, expires_in: expires_in || CACHE_TTL)
     end
   end

6. (optional) override custom cache key data. For default, cache key is defined by URL and query string

   class PostsController < ApplicationController
     before_action :set_shop
   
     def index
       response_cache do
         @post = @shop.posts
         respond_with(@post)
       end
     end
   
     def show
       response_cache do
         @post = @shop.posts.find(params[:id])
         respond_with(@post)
       end
     end
   
     def another_action
       # custom cache key data
       cache_key = {
         action: action_name,
         format: request.format,
         shop_updated_at: @shop.updated_at
         # you may add more keys here
       }
       response_cache cache_key do
         @post = @shop.posts.find(params[:id])
         respond_with(@post)
       end
     end
   
     # override default cache key data globally per class
     def cache_key_data
       {
         action: action_name,
         format: request.format,
         params: params.slice(:id),
         shop_version: @shop.version
         # you may add more keys here
       }
     end
   
     def set_shop
       # @shop = ...
     end
   end

License

ResponseBank is released under the MIT License.

response_bank's Issues

Cacheable's railtie references a middleware class from Shopify

https://github.com/Shopify/cacheable/blob/master/lib/cacheable/railtie.rb#L5

Is there external Documentation or a Case Study on this gem?

Hey this gem looks very useful. I've been googling around and trying to find an article on this gem of the ROI Shopify has seen by using it or any other company. So far I've been unsuccessful.

Does anyone know of any external documentation for case study's for this gem?

I see a similar question was asked back in 2013 but the link doesn't exist anymore: #8

browser can't decompress

this gem was working fine, I was using this gem few months ago

but now I am getting this error:

it's like the body is dumped, but not rendered correctly on browser side
I have tried few times to call render method in response_cache's block argument

Documentation please?

Could you perhaps share a short example of how to use the gem?

So far I get the idea that you add include Cacheable::Controller in a controller... it's a little challenging to decipher without some direction though. Thanks!

Incompatible with latest mocha gem

% bundle install
% bundle exec rake
...
File does not exist: mocha/mini_test

Caused by transitive dependency on mocha which has made an incompatible change, but there doesn't appear to be anything pinning it.

@rafaelfranca

Error pages other than 404s are uncacheable

Currently, response_bank only caches pages if the response code is a 200, 301, or 404:

response_bank/lib/response_bank/middleware.rb

Line 30 in f6754c9

if [200, 404, 301].include?(status) && env['cacheable.miss']

This prevents response_bank from being used to cache error pages other than 404s, even though caching other error pages (such as 429s) would bring the same performance benefits as caching 404 pages.

For example, only the 404 error page would be cached in this example:

class ErrorsController < ApplicationController
  def not_found
    response_cache(error_code: 404) do
      render(template: "errors/not_found", status: :not_found)
    end
  end

  def too_many_requests
    response_cache(error_code: 429) do
      render(template: "errors/too_many_requests", status: :too_many_requests)
    end
  end

  def internal_server_error
    response_cache(error_code: 500) do
      render(template: "errors/internal_server_error", status: :internal_server_error)
    end
  end
end

Caching responses with other error status codes that may depend on the state of the client (e.g. 429s depend on how many times the client has already hit the server) can be tricky, so I would suggest allowing response_bank to accept a configuration option that overrides the default array of cacheable response codes.

Please see https://github.com/Shopify/shopify-app-store/issues/17194 and https://github.com/Shopify/shopify-app-store/pull/17365/files#r901784102 and for more context on why App Store and Theme Store could use this change.

Use this in an API Controller?

I'm not 100% sure this is intended use, but I just bodged my way into adding this to a API controller, and it appears to work. The error that I hit when I first tried was:

A NoMethodError occurred in titles#show:

 undefined method `cache_configured?' for #<Api::V1::TitlesController:0x0000000003e7d8>

     unless cache_configured? && cacheable_req
            ^^^^^^^^^^^^^^^^^
Did you mean?  cache_version_data
 app/controllers/api/v1/titles_controller.rb:9:in `show'

(Rails 7.0.8.1)

And that's confusing, unless this line doesn't do what I imagine it does.

Which led me down the way to a bit of example code in one of the tests, which seems to also work in my API controller. I wonder if this leaves anything out that the other controllers get? All the other (non-API) routes seem to work just fine.

module Api
  module V1
    class TitlesController < ActionController::API
      helper ApplicationHelper, PeopleHelper
      include ResponseBank::Controller # <--- this

      def show
        response_cache do
          @title = Title.published.includes(:headings, :roles, :collections).friendly.find(params[:id])
        end
      end

      private

      # and this method
      def cache_configured?
        true
      end
    end
  end
end

I'm going to try this in production for a couple of minutes, but are there any alarm bells going off for you?