Как работает Middleware в Express?
Эта статья представляет собой адаптированный отрывок из книги «Express API Validation Essentials«. Она научит вас полноценной стратегии валидации API, которую вы можете начать применять в своих Express-приложениях уже сегодня.
Где правильное место для добавления этого middleware в мое приложение?
Почему важен порядок использования middleware?
Как я могу написать свой собственный код для обработки ошибок?
Паттерн middleware является основополагающим при создании приложений на Express, поэтому вам необходимо хорошо понимать, что такое middleware и как оно работает.
В этой статье мы подробно рассмотрим паттерн промежуточного ПО (middleware). Мы также рассмотрим различные типы middleware Express и то, как эффективно сочетать их при создании приложений.
Шаблон Middleware
Когда вы определяете маршрут в Express, функция-обработчик маршрута, которую вы указываете для этого маршрута, является функцией Middleware:
Middleware достаточно гибкое. Вы можете указать Express запускать одну и ту же функцию middleware для различных маршрутов, что позволит вам делать такие вещи, как общая проверка для разных конечных точек API.
Помимо написания собственных функций middleware, вы также можете установить стороннее middleware для использования в вашем приложении. В документации Express перечислены некоторые популярные модули middleware. На npm также доступен широкий спектр модулей middleware Express.
Синтаксис Middleware
Вот синтаксис функции middleware:
Примечание: Вы могли заметить, что я называю req как request, а res как response. Вы можете называть параметры своих промежуточных функций как угодно, но я предпочитаю использовать более четкие имена переменных, поскольку считаю, что так другим разработчикам легче понять, что делает ваш код, даже если они не знакомы с фреймворком Express.
Когда Express запускает функцию middleware, ей передаются три аргумента:
Два типа Middleware
Обычное промежуточное ПО (middleware)
Большинство функций Middleware, с которыми вы будете работать в приложении Express, являются тем, что я называю «простым» промежуточным ПО (в документации Express нет специального термина для них). Они выглядят как функция, определенная в приведенном выше примере синтаксиса middleware (пример 1.2).
Вот пример простой функции middleware:
Middleware для обработки ошибок
Разница между middleware для обработки ошибок и обычным middleware заключается в том, что функции middleware для обработки ошибок задают четыре параметра вместо трех, т.е. (error, request, response, next).
Вот пример функции middleware для обработки ошибок:
Эта промежуточная функция обработки ошибок будет выполнена, когда другая промежуточная функция вызовет функцию next() с объектом ошибки, например.
Использование middleware
Порядок настройки middleware очень важен. Вы можете применить их на трех различных уровнях в вашем приложении:
Если вы хотите, чтобы маршрут (или маршруты) обрабатывал ошибки, которые он вызывает, с помощью middleware для обработки ошибок, вы должны добавить его после определения маршрута.
Давайте рассмотрим, как выглядит настройка middleware на каждом уровне.
На уровне маршрута
Это самый конкретный уровень: любое промежуточное ПО, которое вы настроите на уровне маршрута, будет работать только для этого определенного маршрута.
На уровне маршрутизатора
Express позволяет создавать объекты Router. Они позволяют вам ограничить использование middleware определенным набором маршрутов. Если вы хотите, чтобы одно и то же middleware выполнялось для нескольких маршрутов, а не для всех, то такие объекты могут быть очень полезны.
На уровне приложения
Это наименее специфический уровень. Любое промежуточное ПО, настроенное на этом уровне, будет запущено для всех маршрутов.
Вы должны настраивать middleware на уровне приложения только в случае крайней необходимости, а именно, если его действительно нужно запускать для каждого маршрута в вашем приложении. Каждая функция middleware, независимо от того, насколько она мала, требует определенного времени для выполнения. Чем больше функций middleware необходимо запустить для маршрута, тем медленнее будут выполняться запросы к этому маршруту. Это действительно увеличивается по мере роста вашего приложения и конфигурации с большим количеством middleware. Старайтесь по возможности ограничивать middleware уровнями маршрута или маршрутизатора.
Подведение итогов
В этой статье мы узнали о шаблоне middleware в Express. Мы также узнали о различных типах middleware и о том, как их можно комбинировать при создании приложения на Express.
Если вы хотите прочитать больше о middleware, в документации Express есть несколько руководств:
Эта статья представляет собой адаптированный отрывок из книги «Express API Validation Essentials«. Она научит вас полной стратегии валидации API, которую вы можете начать применять в своих Express-приложениях уже сегодня.
Все коды на изображениях для копирования доступны здесь.
Что такое Middleware или функции связующего программного обеспечения
Что такое middleware?
В одном программном продукте может быть несколько middleware-компонентов, отвечающих за определенную функцию приложения. К примеру, middleware может быть реализован в программе для следующих мероприятий:
Применение middleware в разработке необходимо для выполнения 2-х основных функций:
Как классифицируются middleware?
Условно классификация middleware разделяет их на 2 большие группы:
Где применяются middleware?
Но с другой стороны, middleware-компоненты просто необходимо применять, когда нужно упростить создание распределительной системы, чтобы больше концентрироваться на бизнес-логике своей разработки, а не на отладке взаимодействия между приложениями и ресурсами.
Ну а вообще, middleware очень часто применяются при работе с базами данных различного типа и при наладке взаимодействия между разными приложениями, но при этом нужно применять соответствующие middleware.
На что способен middleware?
Компонент middleware при более детальном рассмотрении может следующее:
Заключение
Что такое middleware — вроде ясно. Мiddleware — это еще один вспомогательный инструмент, который призван облегчить разработку приложений. Пользоваться им или нет — на ваше усмотрение.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
ПО промежуточного слоя ASP.NET Core
Авторы: Рик Андерсон (Rick Anderson) и Стив Смит (Steve Smith)
ПО промежуточного слоя — это программное обеспечение, выстраиваемое в виде конвейера приложения для обработки запросов и откликов. Каждый компонент:
Для построения конвейера запросов используются делегаты запроса. Они обрабатывают каждый HTTP-запрос.
Для их настройки служат методы расширения Run, Map и Use. Отдельный делегат запроса можно указать встроенным в качестве анонимного метода (называемого встроенным ПО промежуточного слоя) либо определить в многоразовом классе. Эти многоразовые классы и встроенные анонимные методы являются ПО промежуточного слоя или компонентами промежуточного слоя. Каждый компонент ПО промежуточного слоя в конвейере запросов отвечает за вызов следующего компонента в конвейере или замыкает конвейер. Когда промежуточный слой замыкает конвейер, он становится терминальным промежуточным слоем, так как препятствует обработке запроса дальнейшими компонентами промежуточного слоя.
В статье миграция обработчиков и модулей HTTP в ASP.NET Core по промежуточного слоя поясняются различия между конвейерами запросов в ASP.NET Core и ASP.NET 4.x, а также приводятся дополнительные примеры ПО промежуточного слоя.
Создание конвейера ПО промежуточного слоя с помощью WebApplication
Конвейер запросов ASP.NET Core состоит из последовательности делегатов запроса, вызываемых один за другим. На следующей схеме демонстрируется этот принцип. Поток выполнения показан черными стрелками.
Каждый из делегатов может выполнять операции до и после следующего делегата. Делегаты обработки исключений должны вызываться в начале конвейера, чтобы перехватывать исключения, возникающие на более поздних этапах.
Простейшее приложение ASP.NET Core задает один делегат запроса, обрабатывающий все запросы. В этом случае конвейер запросов как таковой отсутствует. Вместо этого в ответ на каждый HTTP-запрос вызывается одна анонимная функция.
Не вызывайте next.Invoke после отправки отклика клиенту. Изменения HttpResponse после запуска отклика приведут к возникновению исключения. Таким изменением может быть задание заголовков и кода состояния. Запись в тело отклика после вызова next :
HasStarted удобно использовать для обозначения того, были ли отправлены заголовки или выполнена запись в тело отклика.
Если вы хотите увидеть комментарии к коду, переведенные на языки, отличные от английского, сообщите нам на странице обсуждения этой проблемы на сайте GitHub.
Рекомендуется перегрузка app.Use, требующая передачи контекста далее
Метод расширения app.Use без выделения:
Порядок ПО промежуточного слоя
На следующей схеме показан полный конвейер обработки запросов для приложений ASP.NET Core MVC и Razor Pages. Здесь демонстрируется порядок размещения ПО промежуточного слоя и этапы, на которых добавляется пользовательское ПО промежуточного слоя, в стандартном приложении. Вы можете полностью контролировать изменение порядка существующего ПО промежуточного слоя или внедрять новое пользовательское ПО промежуточного слоя для своих сценариев.
ПО промежуточного слоя конечной точки на предыдущей схеме выполняет конвейер фильтра для соответствующего типа приложения — MVC или Razor Pages.
ПО промежуточного слоя маршрутизации на предыдущей схеме размещено после статических файлов. В таком порядке реализуются шаблоны проектов путем явного вызова app.UseRouting. Если оператор app.UseRouting не вызван, по умолчанию ПО промежуточного слоя маршрутизации запускается в начале конвейера. Дополнительные сведения см. в разделе Маршрутизация.
Порядок, в котором компоненты промежуточного слоя добавляются в файл Program.cs, определяет порядок их вызова при запросах и обратный порядок для откликов. Соблюдать этот порядок крайне важно для обеспечения безопасности, производительности и функциональности.
Следующий выделенный код в Program.cs добавляет связанные с безопасностью компоненты промежуточного слоя в стандартном рекомендуемом порядке:
В приведенном выше коде:
В некоторых сценариях ПО промежуточного слоя имеет другой порядок. Например, порядок кэширования и сжатия зависит от сценария, и существует несколько допустимых вариантов такого порядка. Вот несколько примеров.
С помощью приведенного выше кода можно снизить загрузку ЦП путем кэширования сжатого ответа, но при этом может быть выполнено кэширование нескольких представлений ресурса с помощью разных алгоритмов сжатия, таких как Gzip или Brotli.
В приведенном ниже порядке объединяются статические файлы, чтобы разрешить кэширование сжатых статических файлов.
Следующий код Program.cs добавляет компоненты промежуточного слоя для распространенных сценариев приложений:
В предыдущем примере кода каждый метод расширения ПО промежуточного слоя представляется в WebApplicationBuilder с использованием пространства имен Microsoft.AspNetCore.Builder.
UseExceptionHandler — это первый компонент промежуточного слоя, добавленный в конвейер. Таким образом, обработчик исключений ПО промежуточного слоя перехватывает все исключения, возникающие в последующих вызовах.
Компонент промежуточного слоя для статических файлов вызывается на раннем этапе конвейера, чтобы он мог обработать запросы и выполнить замыкание, минуя остальные компоненты. Этот компонент не выполняет проверки авторизации. Все обрабатываемые им файлы, включая расположенные в wwwroot, находятся в открытом доступе. Сведения о защите статических файлов см. в статье Статические файлы в ASP.NET Core.
Если запрос не обрабатывается компонентом промежуточного слоя для статических файлов, он передается в компонент промежуточного слоя для проверки подлинности (UseAuthentication), который выполняет проверку подлинности. Этот компонент не замыкает запросы, не прошедшие проверку подлинности. Хотя ПО промежуточного слоя для проверки подлинности проверяет подлинность запросов, авторизация (и отклонение) выполняются только после того, как MVC выберет указанную страницу Razor Pages или контроллер MVC и действие.
Следующий пример показывает порядок компонентов промежуточного слоя, где запросы для статических файлов обрабатываются компонентом для статических файлов до компонента для сжатия откликов. Статические файлы не сжимаются с этим порядком ПО промежуточного слоя. Ответы Razor Pages могут быть сжаты.
Дополнительные сведения об одностраничных приложениях см. в руководствах по шаблонам проектов React и Angular.
Порядок ПО промежуточного слоя перенаправления заголовков
ПО промежуточного слоя перенаправления заголовков должно выполняться до другого ПО промежуточного слоя. Такой порядок гарантирует, что ПО промежуточного слоя, полагающееся на сведения о перенаправленных заголовках, может использовать значения заголовков для обработки. Сведения о запуске ПО промежуточного слоя перенаправления заголовков после ПО промежуточного слоя диагностики и обработки ошибок см. в разделе Порядок ПО промежуточного слоя перенаправления заголовков.
Ветвление конвейера ПО промежуточного слоя
Расширения Map используются в качестве соглашения для ветвления конвейера. Map осуществляет ветвление конвейера запросов на основе совпадений для заданного пути запроса. Если путь запроса начинается с заданного пути, данная ветвь выполняется.
В таблице ниже приведены запросы и отклики http://localhost:1234 на базе предыдущего кода.
| Запрос | Ответ |
|---|---|
| localhost:1234 | Hello from non-Map delegate. |
| localhost:1234/map1 | Map Test 1 |
| localhost:1234/map2 | Map Test 2 |
| localhost:1234/map3 | Hello from non-Map delegate. |
Map поддерживает вложение, например:
Map также может сопоставить несколько сегментов одновременно:
Ниже приведены запросы и отклики http://localhost:1234 на базе предыдущего кода.
| Запрос | Ответ |
|---|---|
| localhost:1234 | Hello from non-Map delegate. |
| localhost:1234/?branch=main | Branch used = main |
Встроенное ПО промежуточного слоя
ASP.NET Core содержит следующие компоненты промежуточного слоя. В столбце Порядок указаны сведения о размещении ПО промежуточного слоя в конвейере обработки запросов и условия, в соответствии с которыми ПО промежуточного слоя может прервать обработку запроса. Если промежуточный слой замыкает конвейер обработки запроса и препятствует обработке запроса дальнейшими компонентами промежуточного слоя, он называется терминальным промежуточным слоем. Дополнительные сведения о замыкании конвейера см. в разделе Создание конвейера ПО промежуточного слоя с помощью IApplicationBuilder.
Дополнительные ресурсы
Авторы: Рик Андерсон (Rick Anderson) и Стив Смит (Steve Smith)
ПО промежуточного слоя — это программное обеспечение, выстраиваемое в виде конвейера приложения для обработки запросов и откликов. Каждый компонент:
Для построения конвейера запросов используются делегаты запроса. Они обрабатывают каждый HTTP-запрос.
Для их настройки служат методы расширения Run, Map и Use. Отдельный делегат запроса можно указать встроенным в качестве анонимного метода (называемого встроенным ПО промежуточного слоя) либо определить в многоразовом классе. Эти многоразовые классы и встроенные анонимные методы являются ПО промежуточного слоя или компонентами промежуточного слоя. Каждый компонент ПО промежуточного слоя в конвейере запросов отвечает за вызов следующего компонента в конвейере или замыкает конвейер. Когда промежуточный слой замыкает конвейер, он становится терминальным промежуточным слоем, так как препятствует обработке запроса дальнейшими компонентами промежуточного слоя.
В статье миграция обработчиков и модулей HTTP в ASP.NET Core по промежуточного слоя поясняются различия между конвейерами запросов в ASP.NET Core и ASP.NET 4.x, а также приводятся дополнительные примеры ПО промежуточного слоя.
Создание конвейера ПО промежуточного слоя с помощью IApplicationBuilder
Конвейер запросов ASP.NET Core состоит из последовательности делегатов запроса, вызываемых один за другим. На следующей схеме демонстрируется этот принцип. Поток выполнения показан черными стрелками.
Каждый из делегатов может выполнять операции до и после следующего делегата. Делегаты обработки исключений должны вызываться в начале конвейера, чтобы перехватывать исключения, возникающие на более поздних этапах.
Простейшее приложение ASP.NET Core задает один делегат запроса, обрабатывающий все запросы. В этом случае конвейер запросов как таковой отсутствует. Вместо этого в ответ на каждый HTTP-запрос вызывается одна анонимная функция.
Несколько делегатов запроса можно соединить в цепочку с помощью Use. Параметр next представляет следующий делегат в конвейере. Замыкать конвейер можно не вызывая параметр next. Обычно действия можно выполнять как до, так и после следующего делегата, как показано в этом примере.
Не вызывайте next.Invoke после отправки отклика клиенту. Изменения HttpResponse после запуска отклика приведут к возникновению исключения. Таким изменением может быть задание заголовков и кода состояния. Запись в тело отклика после вызова next :
HasStarted удобно использовать для обозначения того, были ли отправлены заголовки или выполнена запись в тело отклика.
Если вы хотите увидеть комментарии к коду, переведенные на языки, отличные от английского, сообщите нам на странице обсуждения этой проблемы на сайте GitHub.
Порядок ПО промежуточного слоя
На следующей схеме показан полный конвейер обработки запросов для приложений ASP.NET Core MVC и Razor Pages. Здесь демонстрируется порядок размещения ПО промежуточного слоя и этапы, на которых добавляется пользовательское ПО промежуточного слоя, в стандартном приложении. Вы можете полностью контролировать изменение порядка существующего ПО промежуточного слоя или внедрять новое пользовательское ПО промежуточного слоя для своих сценариев.
ПО промежуточного слоя конечной точки на предыдущей схеме выполняет конвейер фильтра для соответствующего типа приложения — MVC или Razor Pages.
Следующий метод Startup.Configure добавляет связанные с безопасностью компоненты ПО промежуточного слоя в стандартном рекомендуемом порядке:
В приведенном выше коде:
В некоторых сценариях ПО промежуточного слоя имеет другой порядок. Например, порядок кэширования и сжатия зависит от сценария, и существует несколько допустимых вариантов такого порядка. Пример:
С помощью приведенного выше кода можно экономить ресурсы ЦП путем кэширования сжатого ответа, но при этом может быть выполнено кэширование нескольких представлений ресурса с помощью разных алгоритмов сжатия, таких как Gzip или Brotli.
В приведенном ниже порядке объединяются статические файлы, чтобы разрешить кэширование сжатых статических файлов.
Метод Startup.Configure добавляет компоненты ПО промежуточного слоя для распространенных сценариев приложений:
В предыдущем примере кода каждый метод расширения ПО промежуточного слоя представляется в IApplicationBuilder с использованием пространства имен Microsoft.AspNetCore.Builder.
UseExceptionHandler — это первый компонент промежуточного слоя, добавленный в конвейер. Таким образом, обработчик исключений ПО промежуточного слоя перехватывает все исключения, возникающие в последующих вызовах.
Компонент промежуточного слоя для статических файлов вызывается на раннем этапе конвейера, чтобы он мог обработать запросы и выполнить замыкание, минуя остальные компоненты. Этот компонент не выполняет проверки авторизации. Все обрабатываемые им файлы, включая расположенные в wwwroot, находятся в открытом доступе. Сведения о защите статических файлов см. в статье Статические файлы в ASP.NET Core.
Если запрос не обрабатывается компонентом промежуточного слоя для статических файлов, он передается в компонент промежуточного слоя для проверки подлинности (UseAuthentication), который выполняет проверку подлинности. Этот компонент не замыкает запросы, не прошедшие проверку подлинности. Хотя ПО промежуточного слоя для проверки подлинности проверяет подлинность запросов, авторизация (и отклонение) выполняются только после того, как MVC выберет указанную страницу Razor Pages или контроллер MVC и действие.
Следующий пример показывает порядок компонентов промежуточного слоя, где запросы для статических файлов обрабатываются компонентом для статических файлов до компонента для сжатия откликов. Статические файлы не сжимаются с этим порядком ПО промежуточного слоя. Ответы Razor Pages могут быть сжаты.
Для одностраничных приложений (SPA) ПО промежуточного слоя SPA UseSpaStaticFiles обычно поступает в конвейер ПО промежуточного слоя последним. ПО промежуточного слоя SPA поступает последним:
Дополнительные сведения об SPA см. в руководствах по шаблонам проектов React и Angular.
Порядок ПО промежуточного слоя перенаправления заголовков
ПО промежуточного слоя перенаправления заголовков должно выполняться до другого ПО промежуточного слоя. Такой порядок гарантирует, что ПО промежуточного слоя, полагающееся на сведения о перенаправленных заголовках, может использовать значения заголовков для обработки. Сведения о запуске ПО промежуточного слоя перенаправления заголовков после ПО промежуточного слоя диагностики и обработки ошибок см. в разделе Порядок ПО промежуточного слоя перенаправления заголовков.
Ветвление конвейера ПО промежуточного слоя
Расширения Map используются в качестве соглашения для ветвления конвейера. Map осуществляет ветвление конвейера запросов на основе совпадений для заданного пути запроса. Если путь запроса начинается с заданного пути, данная ветвь выполняется.
Ниже приведены запросы и отклики http://localhost:1234 на базе предыдущего кода.
| Запрос | Ответ |
|---|---|
| localhost:1234 | Hello from non-Map delegate. |
| localhost:1234/map1 | Map Test 1 |
| localhost:1234/map2 | Map Test 2 |
| localhost:1234/map3 | Hello from non-Map delegate. |
Map поддерживает вложение, например:
Map также может сопоставить несколько сегментов одновременно:
Ниже приведены запросы и отклики http://localhost:1234 на базе предыдущего кода.
| Запрос | Ответ |
|---|---|
| localhost:1234 | Hello from non-Map delegate. |
| localhost:1234/?branch=main | Branch used = main |
Разбираемся с middleware в ASP.NET Core
А пока делимся с вами традиционным полезным переводом.
Этой статья раскрывает концепции Middleware в ASP.NET Core. К концу этой статьи вы получите четкое представление о следующих моментах:
Что такое Middleware?
Почему порядок расположения Middleware имеет значение?
Методы Run, Use и Map.
Как создать собственное Middleware?
Как реализовать просмотр каталогов с помощью Middleware?
Что такое Middleware?
Middleware (промежуточное или связующее программное обеспечение) — это фрагмент кода в конвейере приложения, используемый для обработки запросов и ответов.
Например, у нас может быть middleware-компонент для аутентификации пользователя, middleware-компонент для обработки ошибок и еще один middleware-компонент для обслуживания статических файлов, таких как файлы JavaScript, CSS, разного рода изображения и т. д.
На рисунке ниже показано, как запрос обрабатывается middleware-компонентами.
Как правило, каждое middleware обрабатывает входящие запросы и передает выполнение следующему middleware для дальнейшей обработки.
Но middleware-компонент также может решить не вызывать следующую часть middleware в конвейере. Это называется замыканием (short-circuiting) или завершением конвейера запросов. Замыкание зачастую желательно, поскольку оно позволяет избежать ненужной работы. Например, если это запрос статического файла, такого как файл CSS, JavaScript, изображение и т. д., middleware-компонент для статических файлов может обработать и обслужить этот запрос, а затем замкнуть остальную часть конвейера.
Давайте создадим ASP.NET Core веб-приложение и рассмотрим конфигурацию middleware по умолчанию в методе Configure класса Startup.
Фреймворк ASP.NET Core предоставляет встроенные middleware-компоненты, которые мы можем легко использовать, добавляя в метод Configure. Ознакомьтесь с документацией Microsoft для получения более подробной информации.
Упорядочение Middleware
Middleware-компоненты выполняются в том порядке, в котором они добавляются в конвейер, по этому следует проявлять осторожность и добавлять middleware в правильном порядке, иначе приложение может работать не так, как вы ожидаете. Порядок расположения middleware важен для безопасности, производительности и функциональности.
Следующие middleware-компоненты предназначены для стандартных сценариев приложений и расположены в рекомендуемом порядке:
Методы Run, Use и Map
app.Run()
Этот метод добавляет middleware-компонент в виде Run[Middleware], который выполнится в конце конвейера. Как правило, он действует как замыкающее middleware и добавляется в конце конвейера запросов, поскольку не может вызывать следующий middleware-компонент.
app.Use()
Этот метод используется для конфигурирования нескольких middleware. В отличие от app.Run(), мы можем включить в него параметр next, который вызывает следующий делегат запроса в конвейере. Мы также можем замкнуть (завершить) конвейер, не вызывая параметр next.
Давайте рассмотрим следующий пример с app.Use() и app.Run() и проанализируем результат/ответ:
app.Map()
Этот метод расширения используются как условное обозначение для ветвления конвейера. Map разветвляет конвейер запросов на основе пути запроса. Если путь запроса начинается с указанного пути, ветвь выполняется.
Давайте рассмотрим следующий пример с app.Map() и проанализируем результат/ответ:
В следующей таблице показаны запросы и ответы от localhost с использованием приведенного выше кода.
