Talk:Rack (web server interface)

Why Rack is so significant

Rack is now so significant within the Ruby community that "rack-compliant" is now a technical term.

Wikipedia, however, is likely still PHP ;-)

I will put together some notes on why Rack is so important - even if missing from some standard English WP pages. I can move on to Fr, De and other European pages after.

Quotes: 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. [...] Please note that this API is mainly used by framework developers and usually will not be exposed to framework users. —Preceding unsigned comment added by Grshiplett (talk • contribs) 22:15, 18 December 2009 (UTC)

Why Rack is cool

Quote: 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. —Preceding unsigned comment added by Grshiplett (talk • contribs) 22:16, 18 December 2009 (UTC)

What Rack offers

QUOTE: 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. —Preceding unsigned comment added by Grshiplett (talk • contribs) 22:18, 18 December 2009 (UTC)

Explanation of hello world example

The example is not really clear what the lines in the example do, some more comments would be nice 130.158.109.248 (talk) 02:02, 7 October 2010 (UTC)bob bobberson

Original author

Wasn't chris2 the original author? The main page does not even mention his original nick (or the later one he adopted).

Here is the old link on his blog from 2007:

https://leahneukirchen.org/blog/archive/2007/02/introducing-rack.html

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

I am not 100% certain but I think chris2 was the one who drove rack initially. At the very least he should be mentioned. 2A02:8388:1604:F600:3AD5:47FF:FE18:CC7F (talk) 18:02, 9 July 2021 (UTC) Edit: My bad, he is actually listed on top. I was only looking at "Developers" section right below that. 2A02:8388:1604:F600:3AD5:47FF:FE18:CC7F (talk) 18:03, 9 July 2021 (UTC)