Why Rack

Well for one, it’s light weight. So if you want to deploy your ruby script using CGI, you can do that with Rack.

But let’s say, you want to your script to Mongrel, or WEBRick, or FCGI; you can do that too, and with very few changes to your script. That’s because Rack abstracts all the boilerplate code you would need to work with those servers and bundles it up into a nice interface for you to use.

Oh, and the code to use Rack is very easy. Here’s an example of a Rack app for you:

Examples

%w(rubygems rack haml).each { |dep| require dep }

class IndexPage
  def call(env)
    haml_engine = Haml::Engine.new(File.read('../templates/index.haml'))
    [
      200,
      { "Content-Type" => "text/html" },
      haml_engine.render(Object.new, {})
    ]
  end
end

Rack::Handler::CGI.run(IndexPage.new)

The secret behind Rack is that it will run any ruby object that has a call method and pass in the environment variables to it. In that environment variable, you will find things like HTTP_HOST, or QUERY_STRING, and the like.

If you wanted to have this script now work with WEBRick, no problem.

# Same code as above, with just a little tweak to the last line

Rack::Handler::WEBRick.run(IndexPage.new, :Port => 3000)

Tada! So now you can run a test server without worrying about setting up Apache or Lighttpd.

More Goodness

To make your life easier, Rack also comes with a set of middleware for you to use. Say you have an error in your application. Perhaps you would like to see that error formatted nicely in your browser. You can enable Rack::ShowExceptions. Perhaps you would like the code you have to be reloaded from the server whenever it changes, like when you’re developing your application, then you can use Rack::Reloader.

To use those options, you can write your Rack handler like

app = Rack::Builder.new do
  use Rack::CommonLogger  # apache-like logger
  use Rack::ShowExceptions
  use Rack::Reloader
  use Rack::ShowStatus  # create default pages for common HTTP error codes
  use Rack::Lint  #ensures all applications behave validly
  run Index.new
end
Rack::Handler::WEBRick.run(app, :Port => 3000)

There’s plenty of magic going on with Rack; A magic that does not sacrifice speed and/or flexibility. I would highly recommend giving Rack a look into the next time you want to write a simple web page.

Since you’re using CGI, you don’t _have_ to worry about setting up FCGI, or Mongrel. You can use mod_ruby if you’re using Apache or cgi with Lighttpd.

So now that servers are out of the way, time for some code.

I mentioned that you don’t have to give up HAML. So for that, I propose this little directory structure.

mysite/
   |- templates/
   `- public/

Hopefully you guessed that templates contains your HAML templates and public is the webroot for your site. Now in your public directory, create an index.rb file, and perhaps it could somewhat look like:

require 'rubygems'
require 'haml'
require 'cgi'

# A Hash for all of the variables we want to send to HAML
model = {}

# Why not get the time
model[:time] = Time.now

cgi = CGI.new

# Set up the template
haml_engine = Haml::Engine.new(File.read('../templates/index.haml'))

# Render out the HTML
cgi.out { haml_engine.render(Object.new, model) }

And there’s the tedious code. There are some interesting pieces to notice. For one, when calling cgi.out, that sends out the proper headers out to the browser *(very important)*. Also, this could probably be wrapped up into a nice function to reduce the strain of repeating one’s self.