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
call
s 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