Qu'est-ce que Rack?
Rack fournit une interface minimale entre les serveurs Web prenant en charge les frameworks Ruby et Ruby.
En utilisant Rack, vous pouvez écrire une application Rack.
Rack transmettra le hachage d'environnement (un hachage, contenu dans une demande HTTP d'un client, composé d'en-têtes de type CGI) à votre application de rack qui peut utiliser les éléments contenus dans ce hachage pour faire ce qu'il veut.
Qu'est-ce qu'une application en rack?
Pour utiliser Rack, vous devez fournir une «application» - un objet qui répond à la #callméthode avec le hachage d'environnement comme paramètre (généralement défini comme env). #calldoit renvoyer un tableau d'exactement trois valeurs:
- le code d'état (par exemple «200»),
- une hachage d'en-têtes ,
- le Corps de Réponse (qui doit répondre à la méthode Ruby,
each).
Vous pouvez écrire une application Rack qui retourne un tel tableau - cela sera renvoyé à votre client, par Rack, dans une réponse (ce sera en fait une instance de la classeRack::Response [cliquez pour accéder aux documents]).
Une application en rack très simple:
gem install rack- Créez un
config.rufichier - Rack sait le chercher.
Nous allons créer une petite application en rack qui renvoie une réponse (une instance de Rack::Response) qui est le corps de réponse est un tableau qui contient une chaîne:"Hello, World!" .
Nous allons lancer un serveur local en utilisant la commande rackup .
Lorsque vous visitez le port concerné dans notre navigateur, nous verrons "Bonjour, monde!" rendu dans la fenêtre.
#./message_app.rb
class MessageApp
def call(env)
[200, {}, ['Hello, World!']]
end
end
#./config.ru
require_relative './message_app'
run MessageApp.new
Démarrez un serveur local avec rackupet visitez localhost: 9292 et vous devriez voir «Bonjour, World! rendu.
Ce n'est pas une explication complète, mais essentiellement ce qui se passe ici est que le client (le navigateur) envoie une demande HTTP à Rack, via votre serveur local, et Rack instancie MessageAppet s'exécute call, en passant le hachage d'environnement en tant que paramètre dans la méthode ( lesenv argument).
Rack prend la valeur de retour (le tableau) et l'utilise pour créer une instance de Rack::Responseet la renvoie au client. Le navigateur utilise la magie pour imprimer «Bonjour tout le monde! à l'écran.
Soit dit en passant, si vous voulez voir à quoi ressemble le hachage de l'environnement, placez-le juste en puts envdessousdef call(env) .
Aussi minime soit-elle, ce que vous avez écrit ici est une application Rack!
Faire interagir une application en rack avec le hachage de l'environnement entrant
Dans notre petite application Rack, nous pouvons interagir avec le envhachage (voir ici pour en savoir plus sur le hachage Environnement).
Nous mettrons en œuvre la possibilité pour l'utilisateur d'entrer sa propre chaîne de requête dans l'URL, par conséquent, cette chaîne sera présente dans la demande HTTP, encapsulée en tant que valeur dans l'une des paires clé / valeur du hachage d'environnement.
Notre application Rack accédera à cette chaîne de requête à partir du hachage d'environnement et la renverra au client (notre navigateur, dans ce cas) via le corps de la réponse.
À partir des documents Rack sur le hachage d'environnement:
"QUERY_STRING: la partie de l'URL de demande qui suit le?, Le cas échéant. Peut être vide, mais est toujours obligatoire!"
#./message_app.rb
class MessageApp
def call(env)
message = env['QUERY_STRING']
[200, {}, [message]]
end
end
Maintenant, rackupet visitez localhost:9292?hello( ?helloétant la chaîne de requête) et vous devriez voir «bonjour» rendu dans la fenêtre.
Middleware de rack
Nous allons:
- insérer un morceau de Rack Middleware dans notre base de code - une classe:
MessageSetter ,
- le hachage d'environnement frappera cette classe en premier et sera transmis en tant que paramètre:
env ,
MessageSetterinsérera une 'MESSAGE'clé dans le hachage env, sa valeur étant 'Hello, World!'si env['QUERY_STRING']est vide;env['QUERY_STRING']si non,- enfin, il sera de retour
@app.call(env)- @appêtre la prochaine application de la « pile »: MessageApp.
Tout d'abord, la version «longue»:
#./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
À partir des documents Rack :: Builder, nous voyons queRack::Builder implémente un petit DSL pour construire de manière itérative des applications Rack. Cela signifie essentiellement que vous pouvez créer une «pile» composée d'un ou plusieurs middlewares et d'une application de «bas niveau» vers laquelle envoyer. Toutes les demandes transmises à votre application de niveau inférieur seront d'abord traitées par votre ou vos middleware.
#usespécifie le middleware à utiliser dans une pile. Il prend le middleware comme argument.
Le middleware de rack doit:
- avoir un constructeur qui prend la prochaine application dans la pile comme paramètre.
- répondre à la
callméthode qui prend le hachage d'environnement comme paramètre.
Dans notre cas, le «middleware» est MessageSetter, le «constructeur» est la initializeméthode de MessageSetter , la «prochaine application» dans la pile estMessageApp .
Donc ici, à cause de ce qui se Rack::Builderpasse sous le capot, l' appargument de MessageSetterla initializeméthode est MessageApp.
(faites le tour de la tête avant de continuer)
Par conséquent, chaque élément du middleware `` transmet '' essentiellement le hachage d'environnement existant à l'application suivante de la chaîne - vous avez donc la possibilité de muter ce hachage d'environnement au sein du middleware avant de le transmettre à l'application suivante de la pile.
#runprend un argument qui est un objet qui répond #callet renvoie une réponse de rack (une instance de Rack::Response).
Conclusions
En utilisant Rack::Buildervous pouvez construire des chaînes de middlewares et toute demande à votre application sera traitée à tour de rôle par chaque middleware avant d'être finalement traitée par la dernière pièce de la pile (dans notre cas,MessageApp ). Ceci est extrêmement utile car il sépare les différentes étapes du traitement des demandes. En termes de «séparation des préoccupations», cela ne pourrait pas être beaucoup plus propre!
Vous pouvez construire un «pipeline de demandes» composé de plusieurs middlewares qui traitent de choses telles que:
- Authentification
- Autorisation
- Mise en cache
- Décoration
- Surveillance des performances et de l'utilisation
- Exécution (en fait gérer la demande et fournir une réponse)
(au-dessus des puces d'une autre réponse sur ce fil)
Vous le verrez souvent dans les applications professionnelles Sinatra. Sinatra utilise Rack! Voir ici pour la définition de ce que Sinatra EST !
En guise de note finale, notre config.rupeut être écrit dans un style abrégé, produisant exactement la même fonctionnalité (et c'est ce que vous verrez généralement):
require_relative './message_app'
require_relative './middleware/message_setter'
use MessageSetter
run MessageApp.new
Et pour montrer plus explicitement ce qui MessageAppse passe, voici sa version «longue» qui montre explicitement que #callcrée une nouvelle instance de Rack::Response, avec les trois arguments requis.
class MessageApp
def call(env)
Rack::Response.new([env['MESSAGE']], 200, {})
end
end
Liens utiles
