leah blogs

Dabbling in my own web framework experiments, I noticed that there is a lot of code duplication among frameworks since they essentially all do the same things. And still, every Ruby web framework developer is writing his own handlers for every webserver he wants to use. Hopefully, the framework users are satisfied with that choice.

However, in essence, dealing with HTTP is rather easy. In the end, you get a request and return a response. Let’s do the easiest thing possible: The canonical format of a HTTP request probably is a hash of a CGI-like environment (that’s what most frameworks I’ve looked at deal with, internally), and a response consists of three parts: a status, a set of headers, and a body.

This could be easily mapped onto a method call in Ruby, looking like this:

class HelloWorld
  def call(env)
    [200, {"Content-Type" => "text/plain"}, ["Hello world!"]]
  end
end

You’ve just seen the most simple Rack application.

Rack aims to provide a minimal API for connecting web servers and web frameworks.

Informally, a Rack application is a thing that responds to #call and takes a hash as argument, returning an array of status, headers and a body. The body needs to respond to #each and then successively return strings that represent the response body. The hash given contains a CGI-ish set of environment variables and some special values, like the body stream of the request (env['rack.input']), or information about the run-time environment (e.g. env['rack.run_once']).

Please note that this API is mainly used by framework developers and usually will not be exposed to framework users. It may seem a bit clumsy at first, or you may have expected a more “polished” API, but the important thing is that the API is very simple (notice that it even can be satisfied by a lambda) and not hard to adopt. (The Camping adapter is a mere five lines of code.)

On top of this minimal API, there are libraries for commonly used things like query parsing or cookie handling and provide more convenience (Rack::Request and Rack::Response) that you are free to use if you wish.

But the really cool thing about Rack is that it provides an extremely easy way to combine these web applications. After all, they are only Ruby objects with a single method that matters. And the thing that calls you must not really be a web server, but could as well be a different application! Let me show you a few Rack filters (or “middleware”) that already exist:

• Rack::ShowExceptions catches all thrown exceptions and wraps them nicely in an helpful 500-page adapted from Django.

• Rack::CommonLogger does Apache-style logs.

• Rack::URLMap redirects to different Rack applications depending on the path and host (a very simple router).

There is another tool, Rack::Lint that checks if your applications and filters play nicely with others so everything ought to work together.

What do you gain if your web framework/server/application supports Rack?

• Handlers for WEBrick, Mongrel and plain CGI (soon FastCGI, too), and every new webserver that provides a Rack handler. (Let n and m be the amount of servers and frameworks, without Rack it’s n*m, but with it’s n+m, which means less work for everyone.)

• The possibility to run several applications inside a single webserver without external configuration.

• Easier (integration and functional) testing, since everything can easily be mocked. (Helpers for this are coming soon, too.)

• A greater diversity among frameworks, since writers now can concentrate on the parts that make it special and stop wasting their time on boring things.

• More synergistic effects: Compare “That upload handler you wrote for IOWA is really great, too bad I use Camping.” with “That upload handler you wrote for Rack works great for me too!”

Currently, Rack is supported by Camping (adapter included with Rack) and Ramaze, more adapters are in the works (a Rails one would be a really cool contribution, hint, hint).

(If you are into Python, you’ll notice a lot of similarities between Rack and WSGI and Paste. That’s fully intended, as I think WSGI helped the Python web landscape really a lot.)

A Rubyforge project has been requested, and a first release will happen really soon. If you’d like to help, contact me by mail or via IRC (chris2@#ruby-lang on FreeNode).

NP: Tom Waits—Innocent When You Dream