Rails dopalony Sinatrą
Opublikowane przez Jarosław Zabiełło
Dostępne w Rails 2.x kontrolery rackowe (tzw. metal applications) wprowadzono aby maksymalnie przyśpieszyć działanie Rails (pomijają prawie cały stos wywołań frameworka). Ich wadą jest trochę niewygodna, niskopoziomowa składnia. Z drugiej strony, dzięki Rackowi, istnieje kilka bardzo szybkich mikroframeworków, z których najbardziej znany to Sinatra i Ramaze. Dzięki możliwości wpięcia ich do Rails, uzyskuje się połączenie dużej szybkości z wygodniejszą składnią.
Klasyczny kontroler rackowy, stworzony za pomocą generatora kodu
$ script/generate metal hello
wygląda tak:
require(File.dirname(__FILE__) + "/../../config/environment") unless defined?(Rails)
class Hello
def self.call(env)
if env["PATH_INFO"] =~ /^\/hello/
[200, {"Content-Type" => "text/html"}, ["Hello World!"]]
else
[404, {"Content-Type" => "text/html"}, ["Not Found"]]
end
end
end
Po zastąpieniu go Sinatrą, kod staje się bardziej znośny:
require 'sinatra/base'
class Hello < Sinatra::Base
get '/hello' do
"Hello World!"
end
end
Wydajnościowo (na MacBook Pro 2.16GHz Core2 Duo, Ruby 1.9.1 i Thin 1.2.4 i dla ab -n 10000 -c 10) różnice wyglądają następująco:
- czysty metal: 2054 req/s
- metal z Sinatrą: 1335 req/s
- klasyczny kongtroler: 456 req/s
Co prawda, wciąż czysty kontroler rackowy jest najszybszy, ale zastąpienie go Sinatrą i tak jest dużo szybsze od normalnego kontrolera Rails. Poza tym uzyskujemy uproszczenie kodu (może na podanym, trywialnym przykładzie nie jest to spektakularne, ale przy bardziej złożonym zalety takiego rozwiązania stają się bardziej oczywiste)



W Rails 3 beta 4 Rails::Metal wyleciał z projektu – http://github.com/rails/rails/commit/ed34652d1aca148fea61c5309c1bd5ff3a55abfa
Tak, tekst dotyczył Rails 2. W Rails 3 każda akcja kontrolera jest zarazem końcówka Racka. Poza tym, kontroler może dziedziczyć po AbstractController i domieszkować sobie moduły, jaki potrzebuje. Więc metal controllers nie tam potrzebne.