В Ruby сервер приложений — например Puma, Unicorn или Passenger — обеспечивает запуск приложения и обработку запросов. Rack задаёт интерфейс между сервером и приложением: call(env) возвращает статус, заголовки и тело ответа. Сервер управляет соединениями и выбранной моделью конкурентности; маршрутизация, бизнес-правила и авторизация относятся к приложению, а гарантии транзакций — к СУБД.
Что такое сервер приложений в Ruby?
Сервер приложений принимает запросы, вызывает Ruby-приложение и отправляет ответ. Важно отделять его работу с соединениями и процессами от бизнес-логики Rails и гарантий базы данных.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
В контексте Ruby сервер приложений — это программа, которая запускает веб-приложение и обеспечивает обработку запросов. Примеры — Puma, Unicorn и Passenger. Термин не означает обязательный отдельный компьютер: сервер и приложение могут работать на одной машине или в контейнере.
Типичная цепочка выглядит так: сервер получает HTTP-запрос, формирует окружение Rack, вызывает приложение и передаёт полученный ответ клиенту. Rack — интерфейс взаимодействия, а не бизнес-фреймворк: объект приложения должен отвечать на call(env) и возвращать массив из статуса, заголовков и тела ответа. Rails предоставляет приложение, совместимое с этим интерфейсом. Спецификация Rack
Минимальный пример без Rails:
# config.ru
class MyApp
def call(env)
[200, { 'content-type' => 'text/plain' }, ['Hello']]
end
end
run MyApp.new
Здесь env содержит сведения о запросе, 200 — HTTP-статус, заголовок задаёт тип содержимого, а массив строк служит телом ответа. run регистрирует приложение в конфигурации Rack. Puma умеет загружать config.ru; запись puma MyApp.new не является способом передать ему Ruby-объект. Документация Puma
К обязанностям сервера относятся приём соединений, передача запросов обработчикам и управление их жизненным циклом. Модели конкурентности различаются: Puma поддерживает потоки и кластер из рабочих процессов. Число обработчиков согласовывают с доступной памятью, нагрузкой и пулом соединений БД; увеличение параллельности само по себе не гарантирует ускорения.
При этом сервер выполняет код приложения, но не определяет его бизнес-правила. Проверку прав пользователя, маршрутизацию и прикладные операции реализуют приложение и его библиотеки. ACID-гарантии обеспечиваются механизмами СУБД при корректном использовании транзакций, а не фактом запуска через Puma.
Перед сервером может стоять Nginx для TLS и статики, но это отдельная архитектурная роль: Puma допускает и самостоятельный приём запросов.