Caching in Rails

Introduction

Rails provides several types of caching to help improve the performance of your application. The three most commonly used types of caching are fragment caching, action caching, and HTTP caching. Let’s take a closer look at each type of caching and when to use it.

Page Caching

Page caching is the simplest form of caching available in Rails 7. It involves saving the entire HTML response of a page to a file and serving the same file for subsequent requests. This type of caching is useful for pages that don’t have any dynamic content, such as homepages, about us pages, or other static pages.

To enable page caching, you can use the caches_page method in your controller, like this:

class HomeController < ApplicationController
  caches_page :index

  def index
    # code to render the page
  end
end

In this example, the caches_page method caches the HTML response for the index action of the HomeController class. Whenever a user requests the index page, Rails will serve the cached HTML response instead of rendering the page again.

Fragment Caching:

Fragment caching is used to cache parts of a view that are expensive to generate. For example, if you have a page that includes a list of articles and each article has many comments, rendering the page may take a long time if you have to load all the comments for each article on every request. To speed up the rendering process, you can use fragment caching to cache the comments for each article separately.

To use fragment caching, wrap the expensive code in a cache block like this:

<% cache @article.comments do %>
  <%= render @article.comments %>
<% end %>

This will cache the output of the expensive code and use it on subsequent requests, avoiding the need to regenerate it each time. In this example, the comments for each article are cached separately, so if a new comment is added to one of the articles, only the cached fragment for that article will be invalidated.

Action Caching:

Action Caching works like Page Caching except the incoming web request hits the Rails stack so that before filters can be run on it before the cache is served.

This ensures that any actions needing to take place before the cached copy is hit can be performed. Therefore increasing performance while taking into account the functionality required to access parts of your application.

Suppose you have a before filter that checks whether the user is authorized to view the article. If the user is authorized, the cached copy of the article is served, and if the user is not authorized, the before filter redirects the user to the login page.

Here’s an example of how you can use Action Caching in your Rails 7 application:

class ArticlesController < ApplicationController
  before_action :authenticate_user!, except: [:index, :show]

  def show
    @article = Article.find(params[:id])
    # ... other code to render the article page ...
    cache_action unless current_user.admin?
  end

  private

  def cache_action
    response.headers['Cache-Control'] = 'public, max-age=300'
    expires_in 5.minutes
  end
end

In this example, we have a before_action :authenticate_user!, which ensures that only authenticated users can view the article. In the show action, we use cache_action to cache the output of the action for 5 minutes, but only if the current user is not an admin. This ensures that non-admin users get the cached copy of the article, and the before_filter :authenticate_user! is executed before serving the cached copy.

HTTP Caching:

HTTP caching is used to cache responses from the server and avoid unnecessary network requests. For example, if you have a page that displays a list of products, you can use HTTP caching to allow the client to cache the response and avoid downloading unnecessary data.

To use HTTP caching, add the following code to your controller action:

def index
  @products = Product.all
  fresh_when last_modified: @products.maximum(:updated_at), public: true
end

This will set the Last-Modified and ETag headers on the response, allowing the client to make conditional requests and avoid downloading unnecessary data. In this example, the response will be cached based on the last_modified timestamp of the products, so if a new product is added or an existing product is updated, the cached response will be invalidated and regenerated.

In addition to these types of caching, Rails also provides other caching mechanisms like low-level caching and Russian doll caching. Low-level caching is used to cache arbitrary objects, such as database queries or API responses. Russian doll caching is used to cache nested fragments of a view, which can be useful when you have complex views with many nested elements.

Conclusion

When using caching in your Rails application, it’s important to consider the trade-offs between performance and complexity. Caching can significantly improve the performance of your application, but it can also introduce some complexity and potential issues, such as cache invalidation and cache consistency. Be sure to test your application thoroughly with caching enabled and monitor its performance to ensure that it’s working as expected.

Thanks for reading, see you in the next one!