Deixo aqui meus agradecimentos aos organizadores e ao público presente. Abaixo, segue minha apresentação sobre aplicações Rack.

Nosso primeiro middleware

Se pegarmos o exemplo simples do HelloWorld apresentado no início desta sequência de posts sobre Rack, podemos acomplar um middleware a ele, adicionando funcionalidades extras à aplicação original.

Primeiros, vamos criar nosso Middleware. O exemplo é muito simples. Após imprimirmos um “Hello World!”, vamos informar a hora.

class Middleware
  def initialize(app)
    @app = app
  end

  def call(env)
    status, headers, response = @app.call(env)
    response_body = ""
    response.each { |part| response_body += part }
    response_body += " --- #{Time.now}"
    headers["Content-Length"] = response_body.length.to_s
    [status, headers, [response_body]]
  end
end

Não se assuste se você não entender tudo de cara. A parte mais complicada é cocatenar a informação de tempo na resposta, e isso é feito usando um each, devido ao fato de o response poder ser qualquer objeto que responda a esse método. Além disso, para que nossa resposta seja válida, é interessante colocar no cabeçalho HTTP o comprimento do nosso body.

Mas além do middleware, devemos dizer que nossa aplicação original quer usar ele. E isso deve ser feito em um arquivo .ru:

#config.ru
require 'rack'
require 'middleware'
require 'hello_world'      

use Middleware
run HelloWorld.new

Agora rodando “rackup config.ru” na linha de comando, teremos o seguinte no nosso servidor:

Hello World! — 2009-10-05 14:05:58 -0300

Outros Exemplos de Middlewares

Na primeira parte dessa série de artigos, citei o projeto rack-contrib, que consistia em uma coleção de Middlewares criados pela comunidade e disponibilizado em um único projeto. Além de serem de extrema utilidade no desenvolvimento, eles também servem como um ótimo objeto de estudo para quem quer aprender sobre o funcionamento de um Middleware. Se olharmos o código do exemplo garbagecollection.rb, veremos que o funcionamento é extremamente simples, consistindo apenas de uma chamada forçada do Garbage Collector a cada request na aplicação.

module Rack
  # Forces garbage collection after each request.
  class GarbageCollector
    def initialize(app)
      @app = app
    end

    def call(env)
      @app.call(env)
    ensure
      GC.start
    end
  end
end

Sem entrar no mérito da utilidade do exemplo, é interessante notar a simplicidade do código. Em outro exemplo, podemos ver integração fácil do código do Google Analytics em sua aplicação a com 2 linhas:

require "rack/google_analytics"
use Rack::GoogleAnalytics, :web_property_id => "UA-000000-1"

E o código, propriamente dito, é algo simples:

module Rack #:nodoc:
  class GoogleAnalytics < Struct.new :app, :options

    def call env
      status, headers, response = app.call(env)

      if headers["Content-Type"] =~ /text\/html|application\/xhtml\+xml/
        body = ""
        response.each { |part| body << part }
        index = body.rindex("")
        if index
          body.insert(index, tracking_code(options[:web_property_id]))
          headers["Content-Length"] = body.length.to_s
          response = [body]
        end
      end

      [status, headers, response]
    end

    private

      # Returns JS to be embeded. This takes one argument, a Web Property ID
      # (aka UA number).
      def tracking_code web_property_id
        return <<-EOF


EOF
      end

  end
end

Um outro exemplo interessante é o Middleware CommonLogger, incorporado ao código do projeto Rack. É uma implementação de logs para aplicações Rack, baseada no projeto Commons Logging da Apache . Primeiro, vejamos o código para depois analisar-mos seu funcionamento.

module Rack
  # Rack::CommonLogger forwards every request to an +app+ given, and
  # logs a line in the Apache common log format to the +logger+, or
  # rack.errors by default.
  class CommonLogger
    # Common Log Format: http://httpd.apache.org/docs/1.3/logs.html#common
    # lilith.local - - [07/Aug/2006 23:58:02] "GET / HTTP/1.1" 500 -
    # %{%s - %s [%s] "%s %s%s %s" %d %s\n} %
    FORMAT = %{%s - %s [%s] "%s %s%s %s" %d %s %0.4f\n}

    def initialize(app, logger=nil)
      @app = app
      @logger = logger
    end

    def call(env)
      began_at = Time.now
      status, header, body = @app.call(env)
      log(env, status, header, began_at)
      [status, header, body]
    end

    private

    def log(env, status, header, began_at)
      now = Time.now
      length = extract_content_length(header)

      logger = @logger || env['rack.errors']
      logger.write FORMAT % [
        env['HTTP_X_FORWARDED_FOR'] || env["REMOTE_ADDR"] || "-",
        env["REMOTE_USER"] || "-",
        now.strftime("%d/%b/%Y %H:%M:%S"),
        env["REQUEST_METHOD"],
        env["PATH_INFO"],
        env["QUERY_STRING"].empty? ? "" : "?"+env["QUERY_STRING"],
        env["HTTP_VERSION"],
        status.to_s[0..3],
        length,
        now - began_at ]
    end

    def extract_content_length(headers)
      headers.each do |key, value|
        if key.downcase == 'content-length'
          return value.to_s == '0' ? '-' : value
        end
      end
      '-'
    end
  end
end

Como podemos ver, este é outro exemplo simples de um Middleware muito útil. No método call, é criado um registro simples do momento em que a aplicação principal é chamada, e um método de log pega todas as informações recebidas e formata em uma string que será impressa no servidor. Apesar de parecer difícil de entender a primeira vista, o método log apenas coleta e formata informações contidas no objeto env para adicionar ao log.

Outros Middleware

Existem outros ótimos exemplos de Middlewares pela rede. Optei por citar os mais simples aqui por questões didáticas. Dentre os que eu poderia citar como fundamentais, estão o rack-cache do Ryan Tomayko, que é utilizado largamente em aplicações desenvolvidas com Rails. Posso citar também o “encolhedor” de javascript Javascript Minifier, o criador de responses JSON “Rack::JSONP” também é um bom exemplo, bem como “Rack::MailExceptions” e outros contidos no projeto rack-contrib.

Até o próximo post!

class HelloWorld
  def call(env)
    [200, {"Content-Type" => "text/html"}, "Hello World"]
  end
end

O método def call(env)

Env

O parâmetro recebido pelo método call é uma hash com as propriedades do ambiente do visitante da aplicação. Se alterarmos o nosso HelloWorld para imprimir o objeto env ao invés da string, teremos algo parecido com isso:

{
"REQUEST_METHOD"=>"GET",
"REQUEST_PATH"=>"/",
"REQUEST_URI"=>"/",
"HTTP_VERSION"=>"HTTP/1.1",
"HTTP_HOST"=>"localhost:9292",
"HTTP_USER_AGENT"=>"Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us) AppleWebKit/530.18 (KHTML, like Gecko) Version/4.0.1 Safari/530.18",
"HTTP_ACCEPT"=>"application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5", "HTTP_ACCEPT_LANGUAGE"=>"en-us", "HTTP_ACCEPT_ENCODING"=>"gzip,deflate",
"HTTP_CONNECTION"=>"keep-alive", "GATEWAY_INTERFACE"=>"CGI/1.2",
"SERVER_NAME"=>"localhost",
"SERVER_PORT"=>"9292",
"SERVER_PROTOCOL"=>"HTTP/1.1",
"SERVER_SOFTWARE"=>"Mongrel 1.1.5",
 "PATH_INFO"=>"/",
 "SCRIPT_NAME"=>"",
 "REMOTE_ADDR"=>"127.0.0.1", "rack.version"=>[0, 1], "rack.input"=>#, "rack.errors"=>#>, "rack.multithread"=>true, "rack.multiprocess"=>false, "rack.run_once"=>false, "rack.url_scheme"=>"http",
 "QUERY_STRING"=>""}
 

Dentre as informações impressas, algumas são bem importantes, como:

• REQUEST_METHOD: Informa qual o verbo HTTP (GET, PUT, DELETE…) usado pelo usuário ao acessar a página.
• HTTP_USER_AGENT: Informa o browser do usuário, facilitando o tratamento para browsers diferente em sua aplicação.
• QUERY_STRING: Informa os argumentos passados após o “?” da url, útil para fazer parsing dos parâmetros.

Status

O primeiro objeto retornado no array de resposta é um inteiro, representando o status da resposta que sua aplicação retornará no método. O 200 do nosso exemplo, representa “OK” segundo a especificação do HTTP. É aqui seu controle de exceção jogará aquele lindo “Erro 404″ quando o usuário digitar incorretamente um sub-caminho de sua aplicação. ;-)

HTTP Headers

Cabeçalhos HTTP informam o tipo de retorno do pacote. O segundo objeto do nosso retorno deve OBRIGATORIAMENTE responder a um método “each” e devolver chaves e valores de seus elementos, tipicamente um Hash, como no nosso exemplo. A chave Content-Type, por exemplo, deve retornar o tipo de retorno a ser esperado, podendo ser HTML(“Content-Type” => “text/html”), XML, MP3 (‘Content-Type’ => ‘audio/mp3′), entre outros.

Response Body

O retorno “Body” deve responder ao método each retornando um array de strings. Este será o conteúdo que será apresentado ao usuário no navegador.

ATENÇÃO: Segundo a documentação atual do Rack, o Body não deve mais ser uma simples string(como nos exemplos do post anterior). Aparentemente isto quebrará no Ruby 1.9.

Rack:Builder

É uma ferramenta que nos permite construir aplicações Rack utilizando uma DSL para “costurar” diferentes middlewares e aplicações. Os Builders são os parafusos das estantes, ou a cola que une as estruturas separadas criando uma inteiramente nova. Na verdade, o Builder é o cara que torna o a idéia do Rack tão genial. A facilidade que ele proporciona na criação de Middlewares ficará bem claro no próximo post.

Os métodos fornecidos pela DSL do Buider são:

• run
• use
• map

Rack::Builder#run

É o método que o servidor web procurará para a execução da aplicação Rack. No exemplo abaixo, nosso builder é informado para rodar o bloco chamado clock a cada resquisição à porta 9292. Nada demais, por enquanto. Mas na medida que a aplicação for crescendo, é possível criar estruturas extremamente complexas que veremos posteriormente.

clock = Proc.new {|env| [200, {"Content-Type" => "text/html"}, ["#{Time.now}"]]}
builder = Rack::Builder.new do
  run clock
end
Rack::Handler::Mongrel.run builder, :Port => 9292

Rack::Builder#use

É o método utilizado para acomplar novas middlewares à sua aplicação. No exemplo abaixo, o middleware CommonLogger é adicionado à nossa aplicação com apenas uma linha de código:

clock = Proc.new {|env| [200, {"Content-Type" => "text/html"}, ["#{Time.now}"]]}
builder = Rack::Builder.new do
  use Rack::CommonLogger
  run clock
end
Rack::Handler::Mongrel.run builder, :Port => 9292

CommonLogger é um Middleware que adiciona a funcionalidade de log ao seu servidor. Rodando este exemplo, você terá um log semelhante ao de Rails e Sinatra em seu console, como no exemplo abaixo:

127.0.0.1 – - [25/Sep/2009 17:17:03] “GET / HTTP/1.1″ 200 30 0.0002
127.0.0.1 – - [25/Sep/2009 17:17:14] “GET / HTTP/1.1″ 200 30 0.0002
127.0.0.1 – - [25/Sep/2009 17:17:15] “GET /2 HTTP/1.1″ 200 30 0.0002
127.0.0.1 – - [25/Sep/2009 17:17:28] “GET /testand_log HTTP/1.1″ 200 30 0.0002

Rack::Builder#map

Método utilizado para mapear (jura?) suas rotas HTTP. Não a toa, é semelhante ao routes.rb do Rails, afinal, ambos são implementações diretas das best practices de desenvolvimento web atual.

Para ilustrar, criaremos um exemplo de aplicação que além de informar as horas, oferece um caminho para que o usuário seja informado em que ano ele se encontra.

clock = Proc.new {|env| [200, {"Content-Type" => "text/html"}, ["#{Time.now}"]]}
builder = Rack::Builder.new do
  use Rack::CommonLogger
  map '/' do
    run clock
  end

  map '/year' do
    run Proc.new {|env| [200, {"Content-Type" => "text/html"}, ["#{Time.new.year}"]] }
  end
end
Rack::Handler::Mongrel.run builder, :Port => 9292

Com este exemplo, se após iniciarmos a nossa aplicação tentarmos acessar a url http://localhost:9292/year, receberemos o ano atual em nosso browser.

Ok, mas e rotas aninhadas? Extremamente simples também! Acompanhem o exemplo abaixo.

builder = Rack::Builder.new do
  use Rack::CommonLogger
  map '/' do
    run Proc.new {|env| [200, {"Content-Type" => "text/html"}, ["Welcome to my page"]]}
  end

  map '/clock' do
    map '/' do
      run Proc.new {|env| [200, {"Content-Type" => "text/html"}, ["#{Time.now}"]] }
    end

    map '/year' do
      run Proc.new {|env| [200, {"Content-Type" => "text/html"}, ["#{Time.now.year}"]] }
    end

    map '/hour' do
      run Proc.new {|env| [200, {"Content-Type" => "text/html"}, ["#{Time.now.hour}"]] }
    end    

  end
end
Rack::Handler::Mongrel.run builder, :Port => 9292

Ok, mas nós podemos seguir o conceito de DRY para evitar código desnecessário:

def create_proc(body_return)
  Proc.new {|env| [200, {"Content-Type" => "text/html"}, ["#{body_return}"]]}
end

builder = Rack::Builder.new do
  use Rack::CommonLogger
  map '/' do
    run create_proc('Welcome to my page')
  end

  map '/clock' do
    map '/' do
      run create_proc(Time.now)
    end

    map '/year' do
      run create_proc(Time.now.year)
    end

    map '/hour' do
      run create_proc(Time.now.hour)
    end    

  end
end
Rack::Handler::Mongrel.run builder, :Port => 9292

Desta maneira, criamos uma aplicação com as seguintes rotas disponíveis:

• http://localhost:9292/
• http://localhost:9292/clock
• http://localhost:9292/clock/year
• http://localhost:9292//clock/hour

Cenas do Próximo Capítulo

Após aprendermos o conceito do Rack, sua estrutura e os 3 principais métodos oferecidos para criação de aplicações, nos focaremos na criação de Middlewares no próximo post. Entenderemos seus conceitos e investigaremos alguns exemplos bem sucedidos disponíveis na web. Fiquem ligados!

Introdução da Introdução

Em fevereiro de 2007, Christian Neukirchen postou em seu blog um artigo chamado “Introduzindo Rack” no qual falava sobre a quantidade de código duplicado que ele achava em diferentes Frameworks Web escritos em Ruby. Ao anunciar a sua criação, o autor tocava em um ponto importante aonde escrevia, com razão, sobre um assunto que na verdade não era culpa dos desenvolvedores.

Sendo todos frameworks web, era de se esperar que muitas coisas fossem parecidas. A grande sacada do criador de Rack, foi o fato de ter percebido que web pode, em grande parte, ser resumida como uma série de requisições e respostas HTTP. O resto é framework que vai por cima.

HTTP pode ser resumido de maneira muito simples, como uma série de REQUESTS e RESPONSES. Rack utiliza-se muito bem dessa “simplicidade” para encapsular praticamente todo o controle dessa troca de mensagens em um objeto Ruby. Ao encapsular as requisições HTTP, Rack é capaz de prover interfaces para aplicações entre web servers, web frameworks e middlewares.

O que é Rack?

Podemos considerar o Rack uma especificação para a criação de aplicações web desenvolvidas com ruby. Segundo Dan Webb em sua apresentação “8 minutes on Rack“:

“Se você tem um objeto Ruby que possui um método call cujo o único argumento é env e retorna um array com 3 elementos ([200, {"Content-Type" => "text/html"}, "Hello World!"] ), então ele pode ser conectado a qualquer web server que suporte Rack”

Mas a definição mais simples possível é a que Rack provê uma interface mínima entre web servers e web frameworks escritos em Ruby.

Essa definição é interessante, mas Rack nos proporciona mais que isso. Com seu Builder (que será explorado em um post mais adiante) é possível integrar e ordenar módulos (ou middlewares) empilhados formando uma aplicação com os recursos desde módulos agrupados.

Por que usar Rack?

Oferece controle de requisições, sessões e cookies automaticamente.

Como Rack é uma especificação, desenvolvedores podem criar códigos que funcionam em qualquer aplicação e compartilhar módulos para uso de outros desenvolvedores. Dessa idéia já surgiu o rack-contrib, uma coleção de Midlewares e ferramentas disponível para que qualquer um utilize em sua aplicação.

Desenvolva middlewares que funcionam com Rails, Sinatra, Ramaze…

Qualquer servidor web que ofereça suporte a Rack rodará sua aplicação normalmente. Além disso, ela poderá ser transferida e replicada em servidores diferentes sem a necessidade de configurações diferentes.

A lista de servidores que já suportam Rack é grande. Até agora, os seguintes já suportam:

• Mongrel
• EventedMongrel
• SwiftipliedMongrel
• WEBrick
• FCGI
• CGI
• SCGI
• LiteSpeed
• Thin
• Ebb
• Fuzed
• Phusion Passenger
• Unicorn

Além dos servidores, praticamente todos os frameworks web desenvolvidos em Ruby já possuem adaptadores para Rack. A lista atual inclui os seguintes frameworks:

• Camping
• Coset
• Halcyon
• Mack
• Maveric
• Merb
• Racktools::SimpleApplication
• Ramaze
• Ruby on Rails
• Rum
• Sinatra
• Sin
• Vintage
• Waves
• Wee

Um exemplo minúsculo

O Rack possui uma ferramenta chamada rackup, que roda arquivos do tipo .ru. Neste exemplo, crie um arquivo chamado hello.ru e digite a seguinte linha:

    run Proc.new {|env| [200, {"Content-Type" => "text/html"}, "Hello Horld!"]}

Agora rode o arquivo via linha de comando usando rackup:

> rackup hello.ru

E acesse o seguinte endereço em seu browser: http://localhost:8765/.

Pronto, você acabou de criar a página web no com o menor número de caracteres possível!

Um segundo exemplo um pouco maior

require 'rubygems'
require 'rack'
class HelloWorld
  def call(env)
    [200, {"Content-Type" => "text/html"}, "Hello Horld!"]
  end
 end
Rack::Handler::Mongrel.run HelloWorld.new, :Port => 9292

Apesar de sua função ser a mesma do anterior, este exemplo merece ser explicado. Como todo objeto Rack, nosso exemplo responde a um método call, retornando um array com os três elementos principais do Rack (que serão explicados no próximo post). Após definirmos esse simples método na nossa classe, basta instanciarmos um servidor (Mongrel nesse caso) que receberá requisições por uma porta (9292) e retornará o conteúdo do terceiro objeto do array do método call.

Se esse início já clareou um pouco mais as idéias sobre o Rack, fique ligado para os posts que seguirão a série para saber mais sobre Middlewares, Rails Metal, Builders e todos os outros elementos do maravilhoso mundo ro Rack!