Primeiro de tudo, o Rack é exatamente duas coisas:
- Uma convenção de interface de servidor da web
- Uma jóia
Rack - a interface do servidor da Web
O básico do rack é uma convenção simples. Todo servidor da web compatível com rack sempre chama um método de chamada em um objeto que você fornece a ele e serve o resultado desse método. O rack especifica exatamente como esse método de chamada deve ser e o que ele deve retornar. Isso é tortura.
Vamos fazer uma tentativa simples. Usarei o WEBrick como servidor da web compatível com rack, mas qualquer um deles o fará. Vamos criar um aplicativo Web simples que retorne uma sequência JSON. Para isso, criaremos um arquivo chamado config.ru. O config.ru será chamado automaticamente pelo conjunto de comandos da gem do rack, que simplesmente executará o conteúdo do config.ru em um servidor da web compatível com rack. Então, vamos adicionar o seguinte ao arquivo config.ru:
class JSONServer
def call(env)
[200, {"Content-Type" => "application/json"}, ['{ "message" : "Hello!" }']]
end
end
map '/hello.json' do
run JSONServer.new
end
Como a convenção especifica, nosso servidor possui um método chamado call que aceita um hash do ambiente e retorna uma matriz com o formato [status, headers, body] para o servidor da web servir. Vamos testá-lo simplesmente chamando de rackup. Um servidor compatível com rack padrão, talvez o WEBrick ou Mongrel seja iniciado e aguarde imediatamente a entrega das solicitações.
$ rackup
[2012-02-19 22:39:26] INFO WEBrick 1.3.1
[2012-02-19 22:39:26] INFO ruby 1.9.3 (2012-01-17) [x86_64-darwin11.2.0]
[2012-02-19 22:39:26] INFO WEBrick::HTTPServer#start: pid=16121 port=9292
Vamos testar nosso novo servidor JSON, curvando ou visitando o URL http://localhost:9292/hello.jsone voila:
$ curl http://localhost:9292/hello.json
{ message: "Hello!" }
Funciona. Ótimo! Essa é a base para todo framework web, seja Rails ou Sinatra. Em algum momento, eles implementam um método de chamada, trabalham com todo o código da estrutura e, finalmente, retornam uma resposta na forma típica [status, headers, body].
No Ruby on Rails, por exemplo, as solicitações de rack atingem a ActionDispatch::Routing.Mapperclasse que se parece com isso:
module ActionDispatch
module Routing
class Mapper
...
def initialize(app, constraints, request)
@app, @constraints, @request = app, constraints, request
end
def matches?(env)
req = @request.new(env)
...
return true
end
def call(env)
matches?(env) ? @app.call(env) : [ 404, {'X-Cascade' => 'pass'}, [] ]
end
...
end
end
Então, basicamente, o Rails verifica, dependendo do hash env, se alguma rota corresponder. Nesse caso, ele passa o hash env para o aplicativo para calcular a resposta, caso contrário, ele responde imediatamente com um 404. Portanto, qualquer servidor da Web que seja compatível com a convenção de interface do rack poderá atender a um aplicativo Rails totalmente desenvolvido.
Middleware
O rack também suporta a criação de camadas de middleware. Eles basicamente interceptam uma solicitação, fazem algo com ela e a transmitem. Isso é muito útil para tarefas versáteis.
Digamos que queremos adicionar log ao nosso servidor JSON que também mede quanto tempo uma solicitação leva. Podemos simplesmente criar um registrador de middleware que faça exatamente isso:
class RackLogger
def initialize(app)
@app = app
end
def call(env)
@start = Time.now
@status, @headers, @body = @app.call(env)
@duration = ((Time.now - @start).to_f * 1000).round(2)
puts "#{env['REQUEST_METHOD']} #{env['REQUEST_PATH']} - Took: #{@duration} ms"
[@status, @headers, @body]
end
end
Quando é criado, ele salva uma cópia do aplicativo real do rack. No nosso caso, é uma instância do nosso JSONServer. O rack chama automaticamente o método de chamada no middleware e espera retornar uma [status, headers, body]matriz, assim como nosso JSONServer retorna.
Portanto, nesse middleware, o ponto de partida é adotado, a chamada real para o JSONServer é feita @app.call(env)e o logger gera a entrada de log e, finalmente, retorna a resposta como [@status, @headers, @body].
Para fazer nosso pequeno rackup.ru usar esse middleware, adicione um RackLogger de uso como este:
class JSONServer
def call(env)
[200, {"Content-Type" => "application/json"}, ['{ "message" : "Hello!" }']]
end
end
class RackLogger
def initialize(app)
@app = app
end
def call(env)
@start = Time.now
@status, @headers, @body = @app.call(env)
@duration = ((Time.now - @start).to_f * 1000).round(2)
puts "#{env['REQUEST_METHOD']} #{env['REQUEST_PATH']} - Took: #{@duration} ms"
[@status, @headers, @body]
end
end
use RackLogger
map '/hello.json' do
run JSONServer.new
end
Reinicie o servidor e pronto, ele gera um log em cada solicitação. O rack permite adicionar vários middlewares chamados na ordem em que são adicionados. É apenas uma ótima maneira de adicionar funcionalidade sem alterar o núcleo do aplicativo em rack.
Rack - A jóia
Embora o rack - antes de tudo - seja uma convenção, ele também é uma jóia que fornece ótima funcionalidade. Um deles já usamos para o nosso servidor JSON, o comando rackup. Mas tem mais! A jóia do rack fornece pequenos aplicativos para muitos casos de uso, como servir arquivos estáticos ou mesmo diretórios inteiros. Vamos ver como servimos um arquivo simples, por exemplo, um arquivo HTML muito básico localizado em htmls / index.html:
<!DOCTYPE HTML>
<html>
<head>
<title>The Index</title>
</head>
<body>
<p>Index Page</p>
</body>
</html>
Talvez desejemos servir esse arquivo a partir da raiz do site, então vamos adicionar o seguinte ao nosso config.ru:
map '/' do
run Rack::File.new "htmls/index.html"
end
Se o visitarmos http://localhost:9292, veremos nosso arquivo html perfeitamente renderizado. Isso foi fácil, certo?
Vamos adicionar um diretório inteiro de arquivos javascript, criando alguns arquivos javascript em / javascripts e adicionando o seguinte ao config.ru:
map '/javascripts' do
run Rack::Directory.new "javascripts"
end
Reinicie o servidor e visite http://localhost:9292/javascripte você verá uma lista de todos os arquivos javascript que você pode incluir agora diretamente de qualquer lugar.
