How to Build Sinatra on Rails 3

n Ruby, we have the great fortune to have one major framework (Rails) and a number of minor frameworks that drive innovation forward. One of the great minor frameworks which has been getting a lot of traction recently is Sinatra, primarily because it exposes a great DSL for writing small, single-purpose apps.

Here’s an example of a simple Sinatra application.

class MyApp < Sinatra::Base
  set :views, File.dirname(__FILE__)
  enable :sessions

  before do
    halt if session[:fail] == true
  end

  get "/hello" do
    "Hello world"
  end

  get "/world" do
    @name = "Carl"
    erb :awesomesauce
  end

  get "/fail" do
    session[:fail] = true
    "You failed"
  end
end
There’s a lot of functionality packed into this little package. You can declare some code to be run before all actions, declare actions and the URL they should be routed from, use rendering semantics, and even use sessions.

We’ve been saying that Rails 3 is flexible enough to use as a framework toolkit–let’s prove it by using Rails to build the subset of the Sinatra DSL described above.

Let’s start with a very tiny subset of the DSL:

class MyApp < Sinatra::Base
  get "/hello" do
    "HELLO World"
  end

  post "/world" do
    "Hello WORLD"
  end
end
The first step is to declare the Sinatra base class:

module Sinatra
  class Base < ActionController::Metal
    include ActionController::RackConvenience
  end
end
We start off by making Sinatra::Base a subclass of the bare metal ActionController implementation, which provides just enough infrastructure to get going. We also include the RackConvenience module, which provides request and response and handles some basic Rack tasks for us.

Next, let’s add support for the GET and POST method:

class Sinatra::Base
  def self.inherited(klass)
    klass.class_eval { @_routes = [] }
  end

  class << self
    def get(uri, options = {}, &block)  route(:get,  uri, options, &block) end
    def post(uri, options = {}, &block) route(:post, uri, options, &block) end

    def route(http_method, uri, options, &block)
      action_name = "[#{http_method}] #{uri}"
      @_routes << {:method => http_method.to_s.upcase, :uri => uri,
                   :action => action_name,ptions => options}
      define_method(action_name, &block)
    end
  end
end
We’ve simply defined some class methods on the Sinatra::Base to store off routing details for the get and post methods, and creating a new method named [GET] /hello. This is a bit of an interesting Ruby trick; while the def keyword has strict semantics for method names, define_method allows any string.

Now we need to wire up the actual routing. There are a number of options, including the Rails router (rack-mount, rack-router, and usher are all new, working Rails-like routers). We’ll use Usher, a fast Rails-like router written by Josh Hull.

class << Sinatra::Base
  def to_app
    routes, controller = @_routes, self

    Usher::Interface.for(:rack) do
      routes.each do |route|
        add(route[:uri], :conditions => {:method => route[:method]}.merge(route[:options])).
          to(controller.action(route[:action]))
      end
    end
  end
end
Here, we define to_app, which is used by Rack to convert a parameter to run into a valid Rack application. We create a new Usher interface, and add a route for each route created by Sinatra. Because Usher::Interface.for uses instance_eval for its DSL, we store off the routes and controller in local variables that will still be available in the closure.

One little detail here: In Rails 3, each action in a controller is a valid rack endpoint. You get the endpoint by doing ControllerName.action(method_name). Here, we’re simply pulling out the action named “[GET] /hello” that we created in route.

The final piece of the puzzle is covering the action processing in the controller itself. For this, we will mostly reuse the default action processing, with a small change:

class Sinatra::Base
  def process_action(*)
    self.response_body = super
  end
end
What’s happening here is that Rails does not treat the return value of the action as significant, instead expecting it to be set using render, but Sinatra treats the returned string as significant. As a result, we set the response_body to the return value of the action.

Next, let’s add session support.

class << Sinatra::Base
  def set(name, value)
    send("_set_#{name}", value)
  end

  def enable(name)
    set(name, true)
  end

  def _set_sessions(value)
    @_sessions = value
    include ActionController::Session if value
  end

  def to_app
    routes, controller = @_routes, self

    app = Usher::Interface.for(:rack) do
      routes.each do |route|
        add(route[:uri], :conditions => {:method => route[:method]}.merge(route[:options])).
          to(controller.action(route[:action]))
      end
    end

    if @_sessions
      app = ActionDispatch::Session::CookieStore.new(app, {:key => "_secret_key",
        :secret => Digest::SHA2.hexdigest(Time.now.to_s + rand(100).to_s)})
    end

    app
  end
end
There’s a few things going on here. First, Sinatra provides an API for setting options: setption, :value. In Sinatra, enableption is equivalent to setption, true. To simplify adding new options, we just delegate set :whatever, value to a call to _set_whatever(value).

We then implement _set_sessions(value) to include ActionController::Session, which provides the session helper. In to_app, we wrap the original application in an ActionDispatch::Session::CookieStore if sessions were set.

Next, we want to add in support for callbacks (before do). It’s only a few lines:

class Sinatra::Base
  include AbstractController::Callbacks
end

class << Sinatra::Base
  alias before before_filter
end
Basically, we pull in the normal Rails callback code, and then rename before_filter to before and we’re good to go.

Finally, let’s dig into rendering.

class Sinatra::Base
  include ActionController::RenderingController

  def sinatra_render_file(name)
    render :template => name.to_s
  end

  def sinatra_render_inline(string, type)
    render :inline => string, :type => type
  end

  %w(haml erb builder).each do |type|
    define_method(type) do |thing|
      return sinatra_render_inline(thing, type) if thing.is_a?(String)
      return sinatra_render_file(thing)
    end
  end
end

class << Sinatra::Base
  alias _set_views append_view_path
end
We include the RenderController module, which provides rendering support. Sinatra supports a few different syntaxes for rendering. It supports erb :template_name which renders the ERB template named template_name. It also supports erb "Some String", which renders the string uses the ERB engine.

Rails supports both of those via render :template and render :inline, so we simply defer to that functionality in each case. We also handle Sinatra’s set :views, view_path by delegating to append_view_path.

You can check out the full repository at https://github.com/wycats/railsnatra/

So there you have it, a large subset of the Sinatra DSL written in Rails in under 100 lines of code. And if you want to add in more advanced Rails features, like layouts, flash, respond_to, file streaming, or conditional get support, it’s just a simple module inclusion away.