Причин для соблюдения порядка должно быть минимум, как и подобных зависимостей.
И все должно выполняться максимально асинхронно, иначе потом поулчится роутер express-а.

Если брать хттп, то всевозможные мидлвари спокойно можно уложить в несколько шагов "жизненного цикла" типа: (пре/пост) парсинг, (пре/пост) валидация потом идет сам хендлер и потом (пре/пост) сериализация.

Все что напихивается во внутрь данных шагов выполняется параллельно и без всяких зависимостий друг на друга.

Естественно. Вы должны реализовать эту часть кода сами

Если я не ошибаюсь, то вполне реально сделать обсервер через замыкания

> Причин для соблюдения порядка должно быть минимум

почему?
вполне нормальный кейс: сначала регистрируем запрос, потом проверяем от кого он, потом навешиваем нужную инфу в зависимости от результата предыдущего шага, потом отправляем туда, где он должен быть обработан
каждый из перечисленных шагов должен быть выполнен в именно таком порядке

А потом прямо в хендлере хреначим запрос к БД и сразу возвращаем данные...

В ООП есть паттерн chain of responsibility, практически мидлвары являются плохой реализацией этого паттерна, так что, можно посмотреть как это делают в C# и Java, как это оопшники делают в том же TS

это не ответ
я точно так же мог бы отписаться на реплику
- Все что напихивается во внутрь данных шагов выполняется параллельно и без всяких зависимостий друг на друга
- А потом прямо в хендлере хреначим запрос к БД и сразу возвращаем данные...

Для последовательности асинхронных операциий есть много более безопасных способов асинхронного программирования: промисы и async/await, композиция асинхронных функций (которая может быть параллельная и последовательная), есть фьючеры и можно строить цепочки монад, да что угодно, где можно внятно работать с состоянием, а не примешивать все в req и res

Интересно, как в том же фастифае реализованы before / after хуки, это теже мидлвари? Кто то разбирался?

В веб приложениях роутинг это та часть, через которую проходят все запросы. Каждый написанный там иф добавляет время на обработку, каждая функция которая ждет чего-то от предыдущей то же.

Если у вас сайт для домохозяек, то в принципе это не ощущается и можно добавлять мидлварей сколько влезет. Если у вас что-то более-менее серьезное - то эффект присутствия мидлвари становится заметен сразу, особенно если посмотреть flamegraph.

Если вернуться к експресу с его реализацией, то помимо мидлварей там все остальное тоже плохо. В итоге временная сложность обработки запроса там более O(n*m), где n - количество роутов и мидлварей, а m - длина строки роута.

Хотя при нормальной реализации это легко сводится к максимум O(log2n)

А если у нас система где почти каждый запрос и так дорогой, потому что идёт обращение в базу со сложным поиском, то мы можем пренебречь деталями
Более того, описанное выше никак не отменяет того, что при обработке запроса надо последовательно сделать несколько шагов: залоггировать, проверить, выставить атрибуты и пробросить туда, где запрос и будет обработан (например в дочерний процесс, что ещё добавляет времени)
По-моему нет никакого универсального правила типа "миддлвари антипаттерн"
Да и сами миддлвари, кстати, можно как цепочку обязанностей рассматривать, а можно как builder. И в последнем случае последовательность кажется логичной и необходимой

При этом я согласен с Тимуром, навешивание мусора в req и res (туда, наверное, особенно) это не очень хорошо. Но опять же, универсального правила нет. А миддлварь и вовсе может не навешивать ничего в объект запроса, а формировать свой объект, который идёт рядом с запросом

Спасибо.

Проблема в том, что принцип мидлваров способствует написанию бизнес-логики на обработчиках и перемешиванию бизнес-логики с системным кодом. Да, так не обязательно делать, но так мы видим, что так делают в 100% случаев минус исчезающе малое кол-во.  Это благорядя тому, что у людей нет знания CS, парадигм, паттернов, нет опыта, а есть только 5 минутные обучающие видео, в которых все делается прямо на мидлварах и на примесях. А я наоборот, предлагаю разделить системное программирование и прикладное. Все вещи, которые нужны всегда, как то логирование, слой доступа к данным и пул запросов к данным, парсинг http заголовков, валидация, куки, безопасность и прочее - это явно задачи фреймворка и эти функции не должны кишками вперед торчать к разработчику, чтоб он их прикручивал в каждом проекте, а нужно их только конфигурировать. А бизнес-логика должна быть в виде контрактов или интерфейсов (набор методов и строго описанные типы данных на вход и выход). В этой картине нет места мидлварам.

Здравствуйте! Подскажите пожалуйста - требуется сконвертить  base 64 string => Byte Array на сервере (Сама стринга получена из фотографии) Подскажите пожалуйста как это сделать лучше всего?

Смешались в кучу кони, люди ;)

Миддлвари не виноваты что кто-то их использует не так, как стоило бы. Динамит не виноват, что его используют не только в горной промышленности. Динамит не становится от этого плохим инструментом, и миддлвари тоже

Да, хорошо если фреймворк прячет внутрь низкоуровневые слои и позволяет, например, в декларативном стиле описывать потребности
Но так вот сложился на данный момент мирок ноды, что толковых фреймворков нет, всё либы какие-то типа экспресса. Либо дичайшие монстры типа loopback
(Хотя возможно я тут не прав и nest хороший и всех заборет, посмотрим)
Да и вообще мне кажется что удел ноды это bff на микросервисах. А для микросервисов фреймворк может быть оверхедом, достаточно либы, которая возьмёт на себя рутину. Ну или фреймворка, но конкретно для микросервисов, типа moleculer
А для серьёзного бека есть жаба и c#

Нест - это обертка над экспрессом/фастифаем, которая лишь решает вопрос архитектуры

Здрасте я работала на двух проектах где была нода и не было фронта вообще ) или был но минимальный. Поэтому нода это не только BFF

один - робот (там фронт это железяка что стоит у тебя на столе и общается с node.js по сокетам) и другой подобный - штук 10 микросервисов и только 10% работы это фронт через который загружаются данные в систему

Здравствуйте
Я не отрицаю наличия множества проектов на ноде, не являющихся bff. Сам в таких участвовал
Но если говорить о нише, которая наиболее логично занимается нодой - то получается вот так
Тем более что во втором случае вы сами написали - микросервисы

А ещё есть основания полагать что нода зачастую выбирается тогда, когда команда не умеет и не может (в силу времени, мотивации или способностей) выбрать более подходящий инструмент