Rack - What the hell?

Angelegt von niklas Mon, 05 Jul 2010 15:56:00 GMT

You all know Rack, don't you?

Well if you don't, it boils down to this:

class HelloRack

def call(env)
  [200, { 'Content-Type' => 'text/html' }, ['<h1>', 'Hello World', '</h1>']]
end

end

That is a basic Rack application. It is passed the environment, which feels a lot like CGI 2.0, checkout the spec. To get it up and running, the easiest thing to do is using a rackup recipe:

run HelloRack.new

Put this in a file named "config.ru", fire up the app with "rackup" and hit http://localhost:9292/ with your browser.

That is pretty simple. Now the real power of rack comes with so called Middleware:

class GoodbyeMiddleware

def initialize(app)
  @app = app
end

def call(env)
  if env['PATH_INFO'] == '/bye'
    [200, { 'Content-Type' => 'text/html' }, ['<h1>', 'Goodbye Cruel World', '</h1>']]
  else
    @app.call
  end
end

end

To use it, modify your config.ru look like this:

use GoodbyeMiddleware run HelloRack.new

Restart rackup (CTRL+C to quit, then "rackup" again), then visit http://localhost:9292/ to see the same thing as before. Browsing to http://localhost:9292/bye however, will show you something else.

I hope you got it, if not, read any of the great tutorials and articles about rack.

This is very interesting! But, what do you actually do with it?

Essentially Rack is just a tiny interface between all kinds of ruby-aware webservers and ruby applications. The goal is similar to that of CGI, FastCGI, etc, etc. just... the "Ruby Way"(TM). And we all love ruby, don't we?

Now there are a whole number of things you can do with rack: If you are a Rails developer you can directly incorporate any middleware. Also, there is Rails Metal, which seems to be pretty useless, but nevertheless might be able to give your app a performance hit. If you're riding on Sinatra here are some slides for you.

But if you're (like I am) pretty much frustrated by the drawbacks (regarding performance, extensibility, debuggability...) and limitations (also (mistakenly) known as conventions) existing frameworks give you or just want to really fucking decide for yourself what your framework does and what it doesn't, then Rack can be a great way to roll your own. You focus only on what the framework does, the rest is done by rack.

And after all there are lots of ready-to-use middlewares out there that provide anything you need, right?

Well, so I thought!

If you take a look at the List of Middleware or just do a quick search on github, you'll find tons of apps & middlewares that do just about anything you might ever have thought of doing in a framework.

So, what do we want to do?

  • Routing
    There are a lot of solutions for routing:
    
    • Rack Router Well, that looks very nice. It has a simple DSL and doesn't involve too much magic. Also, it looks like a middleware. But if you take a closer look, you'll see it actually isn't. Had to fix it.
    • Usher Which I haven't tried yet, but will, for a followup article.
  • Authentication
    • Rack::OpenID Is really nice but refuses to work with passenger, which renders it unusable for production. Hint: mod_auth_openid is a great alternative!
    • Warden Is a powerful authentication framework, however it's OpenID Plugin is based on Rack::OpenID, hence suffers from the same drawbacks.
  • Controller
    • rackable Is a simple module to ease the writing of RESTful applications. However, I felt the urge to patch it as well to suit my needs. (The author has a great excuse though: "...I thought it was useless...")

There is a lot more I could write about, but my time is rather limited and I want to save some stuff for a follow up.

Just a quick conclusion:

  • Rack rocks!
  • Don't believe all that is written in the description of the libs you use.
  • Rack apps are easy to write, hence there's a lot of shit out there.
  • Prepare to fork & patch anything you use.
  • RTFC (read the fucking code)!
Trackbacks

Verwenden Sie den folgenden Link zur Rückverlinkung von Ihrer eigenen Seite:
http://praktikanten.brueckenschlaeger.org/trackbacks?article_id=124

Leave a comment

Comments