Size: a a a

NodeUA - JavaScript and Node.js in Ukraine

2020 February 10

A

Alexander in NodeUA - JavaScript and Node.js in Ukraine
Алексей Попов
если кратко - нужен
если более подробно - вот хочется чтобы метрики засекались раньше остальных шагов, например
первое что в голову пришло, в реальности причин соблюдать порядок может быть много
Причин для соблюдения порядка должно быть минимум, как и подобных зависимостей.
И все должно выполняться максимально асинхронно, иначе потом поулчится роутер express-а.

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

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

A

Alexander in NodeUA - JavaScript and Node.js in Ukraine
Алексей Попов
события через event emitter? в общем случае сложно соблюсти порядок обработки событий если в обработчиках начинается асинхронщина
и боюсь что код, который даст такие гарантии, сильно сложнее миддлварей
Естественно. Вы должны реализовать эту часть кода сами
источник

Ц

Це тільки in NodeUA - JavaScript and Node.js in Ukraine
Алексей Попов
ну и это oop-way, а если отказаться от ооп?
в фп мире есть паттерн observer?
Если я не ошибаюсь, то вполне реально сделать обсервер через замыкания
источник

АП

Алексей Попов... in NodeUA - JavaScript and Node.js in Ukraine
Alexander
Причин для соблюдения порядка должно быть минимум, как и подобных зависимостей.
И все должно выполняться максимально асинхронно, иначе потом поулчится роутер express-а.

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

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

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

A

Alexander in NodeUA - JavaScript and Node.js in Ukraine
Алексей Попов
> Причин для соблюдения порядка должно быть минимум

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

TS

Timur Shemsedinov in NodeUA - JavaScript and Node.js in Ukraine
Алексей Попов
а как порядок гарантировать при таком подходе?
В ООП есть паттерн chain of responsibility, практически мидлвары являются плохой реализацией этого паттерна, так что, можно посмотреть как это делают в C# и Java, как это оопшники делают в том же TS
источник

АП

Алексей Попов... in NodeUA - JavaScript and Node.js in Ukraine
Alexander
А потом прямо в хендлере хреначим запрос к БД и сразу возвращаем данные...
это не ответ
я точно так же мог бы отписаться на реплику
- Все что напихивается во внутрь данных шагов выполняется параллельно и без всяких зависимостий друг на друга
- А потом прямо в хендлере хреначим запрос к БД и сразу возвращаем данные...
источник

TS

Timur Shemsedinov in NodeUA - JavaScript and Node.js in Ukraine
Алексей Попов
если кратко - нужен
если более подробно - вот хочется чтобы метрики засекались раньше остальных шагов, например
первое что в голову пришло, в реальности причин соблюдать порядок может быть много
Для последовательности асинхронных операциий есть много более безопасных способов асинхронного программирования: промисы и async/await, композиция асинхронных функций (которая может быть параллельная и последовательная), есть фьючеры и можно строить цепочки монад, да что угодно, где можно внятно работать с состоянием, а не примешивать все в req и res
источник

MD

Mikhail Demidoff in NodeUA - JavaScript and Node.js in Ukraine
Интересно, как в том же фастифае реализованы before / after хуки, это теже мидлвари? Кто то разбирался?
источник

A

Alexander in NodeUA - JavaScript and Node.js in Ukraine
Алексей Попов
это не ответ
я точно так же мог бы отписаться на реплику
- Все что напихивается во внутрь данных шагов выполняется параллельно и без всяких зависимостий друг на друга
- А потом прямо в хендлере хреначим запрос к БД и сразу возвращаем данные...
В веб приложениях роутинг это та часть, через которую проходят все запросы. Каждый написанный там иф добавляет время на обработку, каждая функция которая ждет чего-то от предыдущей то же.

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

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

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

АП

Алексей Попов... in NodeUA - JavaScript and Node.js in Ukraine
Alexander
В веб приложениях роутинг это та часть, через которую проходят все запросы. Каждый написанный там иф добавляет время на обработку, каждая функция которая ждет чего-то от предыдущей то же.

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

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

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

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

ro

roma ogurchik in NodeUA - JavaScript and Node.js in Ukraine
Ivan
Видео не смотрел (и не знаю контекст вопроса), но у нас в чате один парень тоже задал подобный вопрос, то ответ по мидлварям нашли на сайте Уорда Каннингема wiki.c2.com
Спасибо.
источник

TS

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

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

AK

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

MD

Mikhail Demidoff in NodeUA - JavaScript and Node.js in Ukraine
источник

АП

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

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

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

MD

Mikhail Demidoff in NodeUA - JavaScript and Node.js in Ukraine
Алексей Попов
Смешались в кучу кони, люди ;)

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

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

ES

Elena Sharovar in NodeUA - JavaScript and Node.js in Ukraine
Алексей Попов
Смешались в кучу кони, люди ;)

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

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

ES

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

АП

Алексей Попов... in NodeUA - JavaScript and Node.js in Ukraine
Elena Sharovar
Здрасте я работала на двух проектах где была нода и не было фронта вообще ) или был но минимальный. Поэтому нода это не только BFF
Здравствуйте
Я не отрицаю наличия множества проектов на ноде, не являющихся bff. Сам в таких участвовал
Но если говорить о нише, которая наиболее логично занимается нодой - то получается вот так
Тем более что во втором случае вы сами написали - микросервисы

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