¿Qué es el estante?
Rack proporciona una interfaz mínima entre servidores web que admiten los marcos Ruby y Ruby.
Usando Rack puedes escribir una Aplicación Rack.
Rack pasará el hash de entorno (un hash, contenido dentro de una solicitud HTTP de un cliente, que consiste en encabezados similares a CGI) a su aplicación Rack, que puede usar las cosas contenidas en este hash para hacer lo que quiera.
¿Qué es una aplicación de bastidor?
Para usar Rack, debe proporcionar una 'aplicación', un objeto que responde al #callmétodo con el Hash de entorno como parámetro (normalmente definido como env). #calldebe devolver una matriz de exactamente tres valores:
- el código de estado (por ejemplo, '200'),
- un hash de encabezados ,
- el cuerpo de respuesta (que debe responder al método Ruby
each).
Puede escribir una aplicación Rack que devuelva dicha matriz; Rack la enviará de vuelta a su cliente dentro de un Respuesta (en realidad, será una instancia de la Clase Rack::Response[haga clic para ir a los documentos]).
Una aplicación de rack muy simple:
gem install rack- Cree un
config.ruarchivo: Rack sabe buscar esto.
Vamos a crear una pequeña aplicación Rack que devuelve una respuesta (una instancia de Rack::Response) que es la respuesta del cuerpo es una matriz que contiene una cadena de caracteres: "Hello, World!".
Lanzaremos un servidor local usando el comando rackup.
Al visitar el puerto correspondiente en nuestro navegador, veremos "¡Hola, mundo!" prestados en la ventana gráfica.
#./message_app.rb
class MessageApp
def call(env)
[200, {}, ['Hello, World!']]
end
end
#./config.ru
require_relative './message_app'
run MessageApp.new
Inicie un servidor local con rackupy visite localhost: 9292 y debería ver '¡Hola, mundo!' prestados.
Esta no es una explicación completa, pero esencialmente lo que sucede aquí es que el Cliente (el navegador) envía una Solicitud HTTP a Rack, a través de su servidor local, y Rack crea instancias MessageAppy ejecutacall , pasando el Hash del entorno como un parámetro en el método ( el envargumento)
Rack toma el valor de retorno (la matriz) y lo usa para crear una instancia Rack::Responsey lo envía de vuelta al Cliente. El navegador usa magia para imprimir '¡Hola, mundo!' a la pantalla
Por cierto, si quieres ver cómo se ve el hash del entorno, simplemente pon puts env debajodef call(env) .
Minimal como es, ¡lo que has escrito aquí es una aplicación Rack!
Hacer que una aplicación de bastidor interactúe con el hash Entorno entrante
En nuestra pequeña aplicación Rack, podemos interactuar con el envhash (ver aquí para obtener más información sobre el hash del entorno).
Implementaremos la capacidad para que el usuario ingrese su propia cadena de consulta en la URL, por lo tanto, esa cadena estará presente en la solicitud HTTP, encapsulada como un valor en uno de los pares clave / valor del hash del Entorno.
Nuestra aplicación Rack accederá a esa cadena de consulta desde el hash Environment y la enviará de vuelta al cliente (nuestro navegador, en este caso) a través del Cuerpo en la Respuesta.
De los documentos de Rack en Environment Hash:
"QUERY_STRING: la parte de la URL de solicitud que sigue a?, Si la hay. Puede estar vacía, ¡pero siempre es necesaria!"
#./message_app.rb
class MessageApp
def call(env)
message = env['QUERY_STRING']
[200, {}, [message]]
end
end
Ahora, rackupvisite localhost:9292?hello( ?hellosiendo la cadena de consulta) y debería ver 'hola' en la ventana gráfica.
Middleware en rack
Lo haremos:
- insertar una pieza de cremallera Middleware en nuestra base de código - una clase:
MessageSetter,
- el hash Medio Ambiente llegará a esta primera clase y se pasa como un parámetro:
env,
MessageSetterinsertará una 'MESSAGE'clave en el hash env, siendo su valor 'Hello, World!'si env['QUERY_STRING']está vacío; env['QUERY_STRING']si no,- Por último, se volverá
@app.call(env)- @appsiendo la próxima aplicación de la 'pila': MessageApp.
Primero, la versión de 'mano larga':
#./middleware/message_setter.rb
class MessageSetter
def initialize(app)
@app = app
end
def call(env)
if env['QUERY_STRING'].empty?
env['MESSAGE'] = 'Hello, World!'
else
env['MESSAGE'] = env['QUERY_STRING']
end
@app.call(env)
end
end
#./message_app.rb (same as before)
class MessageApp
def call(env)
message = env['QUERY_STRING']
[200, {}, [message]]
end
end
#config.ru
require_relative './message_app'
require_relative './middleware/message_setter'
app = Rack::Builder.new do
use MessageSetter
run MessageApp.new
end
run app
Desde los documentos de Rack :: Builder vemos queRack::Builder implementa un pequeño DSL para construir iterativamente aplicaciones de Rack. Básicamente, esto significa que puede construir una 'Pila' que consta de uno o más Middlewares y una aplicación de 'nivel inferior' para enviar. Todas las solicitudes que pasen a su aplicación de nivel inferior serán procesadas primero por su (s) Middleware (s).
#useespecifica middleware para usar en una pila. Toma el middleware como argumento.
El Middleware de Rack debe:
- tener un constructor que tome la siguiente aplicación en la pila como parámetro.
- responder al
callmétodo que toma el hash de entorno como parámetro.
En nuestro caso, el 'Middleware' es MessageSetter, el 'constructor' es el initializemétodo de MessageSetter , la 'próxima aplicación' en la pila esMessageApp .
Así que aquí, debido a lo que Rack::Builderlo hace bajo el capó, el appargumento de MessageSetter's initializemétodo es MessageApp.
(pon tu cabeza alrededor de lo anterior antes de continuar)
Por lo tanto, cada pieza de Middleware esencialmente 'pasa' el hash del entorno existente a la siguiente aplicación en la cadena, por lo que tiene la oportunidad de mutar ese hash del entorno dentro del Middleware antes de pasarlo a la siguiente aplicación en la pila.
#runtoma un argumento que es un objeto que responde #cally devuelve una Respuesta de rack (una instancia de Rack::Response).
Conclusiones
Utilizando Rack::Builderpuede construir cadenas de Middlewares y cualquier solicitud a su aplicación será procesada por cada Middleware a su vez antes de que finalmente sea procesada por la pieza final en la pila (en nuestro caso,MessageApp ). Esto es extremadamente útil porque separa las diferentes etapas de procesamiento de solicitudes. En términos de 'separación de preocupaciones', ¡no podría ser mucho más limpio!
Puede construir una 'tubería de solicitud' que consta de varios Middlewares que se ocupan de cosas como:
- Autenticación
- Autorización
- Almacenamiento en caché
- Decoración
- Monitoreo de rendimiento y uso
- Ejecución (realmente maneja la solicitud y proporciona una respuesta)
(puntos anteriores de otra respuesta en este hilo)
A menudo verá esto en aplicaciones profesionales de Sinatra. ¡Sinatra usa Rack! Ver aquí para la definición de lo que Sinatra ES !
Como nota final, nuestro config.ruse puede escribir en un estilo de mano corta, produciendo exactamente la misma funcionalidad (y esto es lo que normalmente verá):
require_relative './message_app'
require_relative './middleware/message_setter'
use MessageSetter
run MessageApp.new
Y para mostrar más explícitamente lo que MessageAppestá haciendo, aquí está su versión de 'mano larga' que muestra explícitamente que #callestá creando una nueva instancia de Rack::Response, con los tres argumentos requeridos.
class MessageApp
def call(env)
Rack::Response.new([env['MESSAGE']], 200, {})
end
end
Enlaces útiles
