lacquer

Rails drop in for Varnish support.

Install

Basic installation

sudo gem install lacquer

config/initializers/lacquer.rb

Lacquer.configure do |config|
  # Globally enable/disable cache
  config.enable_cache = true

  # Unless overridden in a controller or action, the default will be used
  config.default_ttl = 1.week

  # Can be :none, :delayed_job, :resque
  config.job_backend = :none

  # Array of Varnish servers to manage
  config.varnish_servers << {
    :host => "0.0.0.0", :port => 6082 # if you have authentication enabled, add :secret => "your secret"
  }

  # Number of retries
  config.retries = 5

  # config handler (optional, if you use Hoptoad or another error tracking service)
  config.command_error_handler = lambda { |s| HoptoadNotifier.notify(s) }
end

app/controllers/application_controller.rb

class ApplicationController < ActionController::Base
  include Lacquer::CacheUtils
end

Usage

To set a custom ttl for a controller:

before_filter { |controller| controller.set_cache_ttl(15.minutes) }

Clearing the cache:

class Posts < ApplicationController
  after_filter :clear_cache, :only => [ :create, :update, :destroy ]

private

  def clear_cache
    clear_cache_for(
      root_path,
      posts_path,
      post_path(@post))
  end
end

Gotchas

The default TTL for most actions is set to 0, since for most cases you’ll probably want to be fairly explicit about what pages do get cached by varnish. The default cache header is typically:

Cache-Control: max-age=0, no-cache, private

This is good for normal controller actions, since you won’t want to cache them. If TTL for an action is set to 0, it won’t mess with the default header.

The key gotcha here is that cached pages strip cookies, so if your application relies on sessions and uses authenticity tokens, the user will need a session cookie set before form actions will work. Setting default TTL to 0 here will make sure these session cookies won’t break.

As a result, all you have to do to set a cacheable action is the before filter above.

Note on Patches/Pull Requests

  • Fork the project.

  • Make your feature addition or bug fix.

  • Add tests for it. This is important so I don’t break it in a future version unintentionally.

  • Commit, do not mess with rakefile, version, or history. (if you want to have your own version, that is fine but bump version in a commit by itself I can ignore when I pull)

  • Send me a pull request. Bonus points for topic branches.

Copyright © 2010 Russ Smith. See LICENSE for details.