Tim Dysinger

In today’s ruby web application landscape, every framework developer is writing his/her own handlers for every server he/she wants to support. This results in semi-duplicate code, if not for the web-server developer then for the framework-developer. This is the pain-point that Rack aims to solve. Rack proposes “why not have some common ground?” Java did this with the Servlet API 10 years ago. Python did this with WSGI 5 years ago.

By leveraging Rack, framework developers and web-server developers gain access to one another without having to write special adapters. Today that’s WEBrick, Mongrel, CGI, Ebb, Fuzed & Thin for web-servers and Rails, Camping, Coset, Halcyon, Maveric, Merb, Racktools::SimpleApplication, Ramaze, Sinatra & Vintage for web-frameworks. (this will undoubtably be outdated by conference time). Tomorrow every new web-server and web-framework that supports Rack can be used together. You’ll be able to pick and choose the best web-server for you without changing your favorite web-framework and vice-versa.

“What do Rails developers really stand to gain today by leveraging Rack?” It might be the ability to run several “rackable” applications side by side inside a single web-server instance. It might be the possibility to leverage or stack applications. You can intercept requests, modify them and pass them through to other handlers. You can also have multiple rackable applications sitting next to each other that comprise one user-facing application. Don’t like file uploads with Rails? Use another web framework or the Rack API directly to write it and place it along side your Rails app in the same application. Want to use single-sign-on for 3 Rails apps? No problem. Rack makes it easy to tie apps together.

Rack Hello World ( gem install rack & mongrel & visit http://localhost:3000 )

%w(rubygems rack).each { |dep| require dep }
Rack::Handler::Mongrel.run(
  lambda { |e| [
      301,
      { ‘Location’ => ‘http://rubyurl.com/g6L’ },
      ’:P’
    ]
  },
  :Port => 3000
)