Что такое стойка?
Rack обеспечивает минимальный интерфейс между веб-серверами, поддерживающими платформы Ruby и Ruby.
Используя Rack, вы можете написать приложение Rack.
Rack передает хэш Environment (Hash, содержащийся внутри HTTP-запроса от клиента, состоящего из CGI-подобных заголовков) в ваше приложение Rack, которое может использовать вещи, содержащиеся в этом хэш-функции, для выполнения чего угодно.
Что такое приложение для стойки?
Чтобы использовать Rack, вы должны предоставить «приложение» - объект, который отвечает на #callметод с помощью Hash среды в качестве параметра (обычно определяется как env). #callдолжен вернуть массив из ровно трех значений:
- код состояния (например , «200»),
- Хэш заголовков ,
- Response Body (который должен ответить методом на Ruby
each).
Вы можете написать приложение Rack, которое возвращает такой массив - оно будет отправлено обратно вашему клиенту Rack внутри Response (на самом деле это будет экземпляр класса Rack::Response[щелкните, чтобы перейти к документам]).
Очень простое приложение для стойки:
gem install rack- Создайте
config.ruфайл - Rack знает, как искать это.
Мы будем создавать крошечный Rack приложение , которое возвращает ответ (экземпляр Rack::Response) , который Ответное Тело представляет собой массив , который содержит строку: "Hello, World!".
Мы запустим локальный сервер с помощью команды rackup.
При посещении соответствующего порта в нашем браузере мы увидим «Hello, World!» отображается в окне просмотра.
#./message_app.rb
class MessageApp
def call(env)
[200, {}, ['Hello, World!']]
end
end
#./config.ru
require_relative './message_app'
run MessageApp.new
Запустите локальный сервер rackupи посетите localhost: 9292, и вы должны увидеть «Hello, World!» оказаны.
Это не исчерпывающее объяснение, но, по сути, здесь происходит то, что Клиент (браузер) отправляет HTTP-запрос в Rack через ваш локальный сервер, а Rack создает MessageAppи запускает его call, передавая Хэш среды как параметр в метод ( envаргумент).
Rack принимает возвращаемое значение (массив) и использует его для создания экземпляра Rack::Responseи отправляет его обратно клиенту. Браузер использует магию, чтобы напечатать «Hello, World!» на экран.
Между прочим, если вы хотите увидеть, как выглядит хеш среды, просто поместите puts envпод ним def call(env).
Как минимум, то, что вы написали здесь, это приложение Rack!
Создание приложения Rack для взаимодействия с хэшем Incoming Environment
В нашем маленьком приложении Rack мы можем взаимодействовать с envхэшем (см. Здесь для получения дополнительной информации о хэше Environment).
Мы реализуем возможность для пользователя вводить свою собственную строку запроса в URL, следовательно, эта строка будет присутствовать в HTTP-запросе, инкапсулируясь в качестве значения в одну из пар ключ / значение хэша Environment.
Наше приложение Rack получит доступ к этой строке запроса из хэша Environment и отправит ее обратно клиенту (в нашем случае, нашему браузеру) через тело в ответе.
Из документов Rack по хэшу среды:
"QUERY_STRING: часть URL запроса, которая следует за?, Если есть. Может быть пустой, но всегда обязательна!"
#./message_app.rb
class MessageApp
def call(env)
message = env['QUERY_STRING']
[200, {}, [message]]
end
end
Теперь rackupи перейдите на страницу localhost:9292?hello( ?helloявляющуюся строкой запроса), и вы должны увидеть 'hello' в окне просмотра.
Стойка Middleware
Мы будем:
- вставить кусок Rack Middleware в нашу кодовую - класс:
MessageSetter,
- хэш - среда ударит этот класс первым и будет принят в качестве параметра:
env,
MessageSetterвставит 'MESSAGE'ключ в окр хэш, его значение существо , 'Hello, World!'если env['QUERY_STRING']пусто; env['QUERY_STRING']если не,- наконец, он вернется
@app.call(env)- @appбыть следующим приложением в «Стек»: MessageApp.
Во-первых, версия «с длинными руками»:
#./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
Из документов Rack :: Builder мы видим, что Rack::Builderреализует небольшой DSL для итеративного конструирования приложений Rack. В основном это означает, что вы можете создать «стек», состоящий из одного или нескольких промежуточных программ и приложения «нижнего уровня» для отправки. Все запросы, поступающие в ваше приложение нижнего уровня, будут сначала обрабатываться вашим Middleware (s).
#useуказывает промежуточное программное обеспечение для использования в стеке. Он принимает промежуточное программное обеспечение в качестве аргумента.
Стойка Middleware должна:
- есть конструктор, который принимает следующее приложение в стеке в качестве параметра.
- Ответьте на
callметод, который принимает хэш Environment в качестве параметра.
В нашем случае «Middleware» - MessageSetterэто «конструктор» - это initializeметод MessageSetter , «следующее приложение» в стеке MessageApp.
Так вот, из - за того, что Rack::Builderделает под капотом, appаргумент MessageSetter«S initializeметода является MessageApp.
(обдумайте вышеизложенное, прежде чем двигаться дальше)
Таким образом, каждый компонент Middleware по существу «передает» существующий хэш среды следующему приложению в цепочке, поэтому у вас есть возможность изменить этот хэш среды в Middleware, прежде чем передать его следующему приложению в стеке.
#runпринимает аргумент, который является объектом, который отвечает #callи возвращает Rack Response (экземпляр Rack::Response).
Выводы
Используя его, Rack::Builderвы можете создавать цепочки промежуточного программного обеспечения, и любой запрос к вашему приложению будет обрабатываться каждым промежуточным ПО по очереди, прежде чем окончательно обрабатывается последним элементом в стеке (в нашем случае, MessageApp). Это чрезвычайно полезно, поскольку разделяет различные этапы обработки запросов. С точки зрения «разделения интересов», это не может быть намного чище!
Вы можете создать «конвейер запросов», состоящий из нескольких промежуточных программ, которые имеют дело с такими вещами, как:
- Аутентификация
- авторизация
- Кэширование
- Украшение
- Мониторинг производительности и использования
- Выполнение (на самом деле обработать запрос и предоставить ответ)
(выше пул из другого ответа в этой теме)
Вы часто будете видеть это в профессиональных приложениях Sinatra. Синатра использует Rack! Смотрите здесь для определения того , что Синатра IS !
В заключение отметим, что наша версия config.ruможет быть написана в сокращенном стиле, предоставляя точно такую же функциональность (и именно это вы обычно увидите):
require_relative './message_app'
require_relative './middleware/message_setter'
use MessageSetter
run MessageApp.new
И чтобы более четко показать, что MessageAppделает, вот его «длинная» версия, которая явно показывает, что #callсоздается новый экземпляр Rack::Response, с требуемыми тремя аргументами.
class MessageApp
def call(env)
Rack::Response.new([env['MESSAGE']], 200, {})
end
end
Полезные ссылки
