Rack has finally seen its 1.0 release a few weeks ago, introducing some backwards-incompatible changes to its specification and several updates and bug fixes since the last version.
Rack has become an important cornerstone of the Ruby web server and framework landscape. Before Rack, frameworks and servers had to be adapted to each others interfaces to work together. With Rack, there's a minimal API that wraps HTTP requests and responses, making the life of framework, server and application developers much more comfortable.
Rack has been widely adopted by the Ruby community, which reflects in the list of support servers:
These frameworks include Rack adapters in their distributions:
- Mongrel
- EventedMongrel
- SwiftipliedMongrel
- WEBrick
- FCGI
- CGI
- SCGI
- LiteSpeed
- Thin
- Ebb
- Fuzed
- Phusion Passenger (which is mod_rack for Apache and for nginx)
- Unicorn
- Camping
- Coset
- Halcyon
- Mack
- Maveric
- Merb
- Racktools::SimpleApplication
- Ramaze
- Ruby on Rails
- Rum
- Sinatra
- Sin
- Vintage
- Waves
- Wee
Rack also provides a basis for other software to provide features independently of frameworks, for example Rack::Cache.
We talked to Christian Neukirchen, the original developer of Rack to find out what he has in mind for Rack's future.
For the near future, we mostly will be bugfixing with only slight improvements to the specification. It is important that Rack stays stable and can be relied upon.
Are there other things that can be factored out of frameworks and be put into Rack?
I try to keep Rack small and focused, libraries and middleware related to special needs are better off as separate projects with their own maintainers and active community. Also, Rack should not restrict the frameworks in their ways of doing things.
More on Rack can be found on the Rack web site and in the 1.0 release announcement.