Обработка HTTP-запроса в Iron строится вокруг последовательной цепочки этапов, в которой каждый шаг формирует контекст выполнения, влияет на поток данных и определяет итоговую структуру ответа.
На уровне сервера входящий HTTP-запрос попадает в транспортный слой Node.js, после чего передаётся в ядро Iron. На этом этапе создаётся объект контекста выполнения запроса, включающий:
request с заголовками, методом, URL и
теломresponseКонтекст выступает единым контейнером состояния, через который проходят все последующие стадии жизненного цикла.
Перед маршрутизацией запрос проходит через цепочку глобальных middleware. Эти функции выполняются последовательно и могут:
Модель построена на принципе «коридора обработки», где каждый middleware получает контроль над потоком выполнения и может передать его дальше через явный переход.
Ключевым свойством этого этапа является возможность асинхронной обработки. Middleware может приостанавливать выполнение до завершения операций ввода-вывода, не блокируя основной поток сервера.
После прохождения глобального слоя выполняется сопоставление запроса с зарегистрированными маршрутами. Маршрутизатор анализирует:
Результатом становится выбор конкретного обработчика, связанного с маршрутом. Если соответствие не найдено, управление передаётся в механизм обработки ошибок уровня «404».
Перед передачей управления в обработчик маршрута выполняется стадия нормализации входных данных. В зависимости от конфигурации системы могут быть активированы:
На этом этапе часто подключаются схемы валидации, которые позволяют гарантировать структуру данных до попадания в бизнес-логику. При нарушении условий выполнение перенаправляется в обработчик ошибок валидации.
Основной этап жизненного цикла связан с вызовом функции обработчика. Она получает доступ к контексту запроса и управляет формированием результата.
Внутри обработчика обычно выполняются:
Execution model поддерживает асинхронные операции через
async/await, что позволяет выстраивать линейную логику
поверх неблокирующего ввода-вывода.
Контекст при этом может расширяться: добавляются промежуточные результаты, вычисленные значения, кэшированные данные.
После завершения обработчика результат передаётся в слой постобработки. Этот этап отвечает за:
Если обработчик вернул сырые данные, система приводит их к корректному HTTP-ответу, учитывая конфигурацию приложения.
Механизм ошибок встроен в каждый этап жизненного цикла. При возникновении исключения управление передаётся в специализированную цепочку error-handlers.
Типовые сценарии:
Error-handlers получают доступ к контексту запроса и могут формировать отдельный формат ответа, не зависящий от стандартного потока обработки.
Важным свойством является возможность централизованного перехвата ошибок на любом этапе цепочки.
После завершения всех преобразований формируется финальный HTTP-ответ. На этом этапе выполняются:
После отправки ответ считается завершённым, а контекст запроса закрывается.
Iron предоставляет систему хуков, позволяющую подключаться к ключевым точкам жизненного цикла. Основные точки расширения:
Хуки позволяют реализовывать кросс-срезные задачи:
Каждый хук получает доступ к текущему состоянию запроса, что обеспечивает гибкость расширения без изменения основной логики.
Жизненный цикл запроса в Iron полностью ориентирован на неблокирующую модель. Все этапы, начиная с middleware и заканчивая обработчиком, могут выполняться асинхронно.
Это приводит к следующим особенностям:
Асинхронность пронизывает весь жизненный цикл, формируя единый поток управления через промисы и контекст выполнения.
Каждый запрос получает собственный независимый контекст. Это означает:
Контекст живёт только в пределах одного жизненного цикла и уничтожается после отправки ответа, что исключает утечки состояния между запросами.
После отправки ответа происходит финальная стадия:
Система возвращается в состояние ожидания следующего запроса, сохраняя минимальный накладной расход между циклами обработки.