O Rack finalmente chegou no seu release 1.0 a poucas semanas atrás, introduzindo algumas mudanças incompatíveis a um tempo atrás para essa especificação e várias atualizações e correções de bug desde a última versão.
Rack tem se tornado importante para os servidores web e frameworks Ruby. Antes do Rack, frameworks e servidores tinham que se adaptar em cada uma das outras interfaces para trabalharem juntos. Com Rack, existe uma API mínima que encapsula HTTP requests e responses, fazendo a vida de framework, servidores e desenvolvedores de aplicações muito mais confortáveis.
Rack tem sido amplamente adotado pela comunidade Ruby, o qual reflete na lista de servidores suportados:
Esses frameworks incluem adaptadores Rack na distribuição deles:
- Mongrel
- EventedMongrel
- SwiftipliedMongrel
- WEBrick
- FCGI
- CGI
- SCGI
- LiteSpeed
- Thin
- Ebb
- Fuzed
- Phusion Passenger (que é mod_rack para Apache e para nginx)
- Unicorn
- Camping
- Coset
- Halcyon
- Mack
- Maveric
- Merb
- Racktools::SimpleApplication
- Ramaze
- Ruby on Rails
- Rum
- Sinatra
- Sin
- Vintage
- Waves
- Wee
Rack também fornece o básico para outros softwares para ter funcionalidades independentemente de frameworks, por exemplo Rack::Cache.
Nós falamos com Christian Neukirchen, o desenvolvedor original do Rack para descobrir o que ele tem em mente para o futuro do Rack.
Para o futuro próximo, iremos corrigir bugs com apenas ligeiras melhorias na especificação. É importante que o Rack fique estável e poder ser invocado.
Existe outras coisas que podem ser refatoradas e colocadas dentro do Rack?
Eu tento manter Rack pequeno e focado, bibliotecas e middleware relacionados a necessidades especiais são melhores fora e como projetos separados com seus próprios mantenedores e sua comunidade ativa. Também, Rack não deve restringir o framework na sua maneira de fazer as coisas.
Mais sobre o Rack pode ser encontrado no web site do Rack e no anúncio do release 1.0.