Tan populares como Ruby and Rails, parece que este problema ya estaría resuelto. JRuby y mod_rails son buenos y elegantes, pero ¿por qué no hay un mod de Apache para Ruby?¿Por qué aún no hay una mod_ruby viable para Apache?
El problema básico es este: durante mucho tiempo, la resonancia magnética fue la única implementación de Ruby posible. La resonancia magnética tiene una serie de problemas que dificultan su inclusión en otra aplicación (que es básicamente lo que hace mod_ruby: incorpora MRI en Apache), especialmente una de múltiples subprocesos (que es Apache). No es particularmente seguro para subprocesos y tiene bastante estado global.
Este estado global significa por ejemplo que si una aplicación Rails modifica alguna clase, entonces todas las demás aplicaciones Rieles que se ejecutan en el mismo servidor Apache, se también ver esta clase modificada.
Otro problema es que el código fuente de MRI no es fácilmente pirateable. La resonancia magnética ahora tiene más de 15 años y está comenzando a mostrarse.
Como resultado de estos problemas, mod_ruby nunca ha realmente funcionaba correctamente, y en algún momento los mantenedores simplemente se dieron por vencidos.
El intérprete de PHP basado en C, por otro lado, se diseñó desde el primer día para ejecutarse como mod_php dentro de Apache. De hecho, para las primeras dos versiones, ni siquiera había una versión de línea de comandos del intérprete, mod_php era el único forma de ejecutar PHP.
Phusion Passenger (aka mod_rack aka mod_rails) resuelve este problema básicamente desistiendo y eludiendo el problema: simplemente ejecutan una copia separada de MRI en un proceso separado para cada aplicación. Funciona de maravilla, y no solo para Ruby. Es compatible con WSGI (interfaz estándar para Python Web Frameworks), Rack (interfaz estándar para Ruby Web Frameworks) y soporte directo para Ruby on Rails.
Mis esperanzas están en mod_rubinius, que desafortunadamente todavía no existe. Rubinius se diseñó desde el principio para que sea seguro para subprocesos, incrustable, sin estado global, no utilice la pila C, etc. Fue diseñado para poder ejecutar múltiples máquinas virtuales Rubinius dentro de un proceso Rubinius. Esto hace que mod_rubinius sea infinitamente más fácil de implementar y mantener que mod_ruby. Lamentablemente, por supuesto, Rubinius aún no se ha lanzado, y el verdadero trabajo en mod_rubinius no puede comenzar hasta que se libera Rubinius. La buena noticia es que mod_rubinius ya tiene más personal detrás que mod_ruby, porque ha pagado a los desarrolladores que trabajan en él por una empresa de hosting Rails que desesperadamente quiere usarlo.
Hay uno: mod_ruby, pero no se ha mantenido en aproximadamente 2 años.
Hay Phusion Passenger, un robusto módulo Apache que puede ejecutar las aplicaciones Rack con la configuración mínima. Se está convirtiendo en un llamamiento a los servidores compartidos, y convertir cualquier programa en una aplicación Rack es ridículamente fácil:
Una aplicación Rack es un rubí objeto (no una clase) que responde a
call. Se necesita exactamente un argumento , el medio ambiente y devuelve una matriz de exactamente tres valores : El estado, las cabeceras , y el cuerpo.
Quizás valga la pena aclarar doblemente el punto de mislav de que mod_rails no está realmente limitado al código de Rails. El nuevo nombre, mod_rack, es mucho mejor. Trivialmente pequeñas aplicaciones pueden ser de montaje en rack - siendo su ejemplo:
class HelloWorld
def call(env)
[200, {"Content-Type" => "text/plain"}, ["Hello world!"]]
end
end