используй преттир и не парься

улыбнуло.. то ли от слова претить, то ли притирать ?

эвенты ужасны с т.зр. навигации по коду и когда надо понять "что вообще тут происходит". ну и соответственно прекрасны для разделения аспектов, плагинизации кода, для организации работы большого числа команд над общим проектом или его частью. для всего есть свои применения, и для эвентов, и для очередей, и для message passing, и для стримов. и они не взаимоисключающие, можно использовать все эти концепты или любую их комбинацию в одном решении

эвенты прекрасны, особенно в микросервисах навигация по коду это уже проблема блокнотов которые вы используете

не соглашусь про блокнот. вот например мне нужно разобраться что происходит, как работает система. я читаю код, дохожу до того что сервис запостил эвент. а что при этом происходит? как быстро найти все микросервисы которые на эвент подписаны? хочется экспериенс типа как "find all references"... а по факту придется скорее всего бегать в клауд и смотреть сабскрипшены. а если их 200 штук, офигеешь искать. а если на каждый чих постится по эвенту, то через пару дней на стенку полезешь

и я такие системы видел, это реальная ситуация.

я и говорю что это проблема блокнота

ты по вызовам можешь прыгать через ctrl+click на объявление функции

ctrl+click по функции показывает все вызовы

я и говорю что это проблема блокнота

+

что мешает так же сделать для ивентов?

ctrl+click по функции показывает все вызовы

какой же должен блокнот быть чтобы вытаскивать информацию о сабскрибшенах из облака?

а чем тебе тут любой другой подход поможет?

и вообще то что происходит в других сервисах тебя волновать не должно

не соглашусь про блокнот. вот например мне нужно разобраться что происходит, как работает система. я читаю код, дохожу до того что сервис запостил эвент. а что при этом происходит? как быстро найти все микросервисы которые на эвент подписаны? хочется экспериенс типа как "find all references"... а по факту придется скорее всего бегать в клауд и смотреть сабскрипшены. а если их 200 штук, офигеешь искать. а если на каждый чих постится по эвенту, то через пару дней на стенку полезешь

для этого обычно создают некую систему которая обрабатывает бизнес процессы, грубо говоря у тебя на один евент может быть только один обработчик, а он уже сам запускает нужный сценарий (если нужно дернуть кучу микросервисов - дергает их). Классический пример такой: появился новый товар - запустился сценарий который 1. Евент добавления товара в БД бух учета (получили в ответ какие-то доп данные - скажем ставка НДС) 2. Выкинули событие добавления товара в складской учет .... 5. Profit

и вообще то что происходит в других сервисах тебя волновать не должно

ну такое - при минимально сложной БЛ - будет писать очень сложно, я уже молчу про консистентность данных

а чем тебе тут любой другой подход поможет?

ну в большинстве других подходов recipient известен на стадии вызова. а в event-ах неизвестен. на эвент можно и динамически подписываться в рантайме, т.е. на стадии компиляции вообще из серии "а хрен его знает что там произойдёт"

и вообще то что происходит в других сервисах тебя волновать не должно

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

Быстрый вопрос. Как вот это переписать во что то менее стремное?

Object.values(result.data.data)[0]["clientid"] )

структура приходящая из api такая { '8023': { clientid: '8023' } }

как процесс происходит? один микросервис завершил работу, запустил эвент, его подхватило 5 сервисов, что-то сделали, записалм результаты своей работы в очередь, потом еще один сервис начинает все эти пакеты из очередей склеивать и т.п.

нужен не столько сам ID сколько факт что пришел хоть один, при проверки уникальности..

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

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

нужен не столько сам ID сколько факт что пришел хоть один, при проверки уникальности..

по Object.keys?

а если у вас 100500 сервисов и большая команда, то всё остальное тебя волновать не должно, да и не уследишь за всеми изменениями

и как правило ты знаешь только те сервисы с которыми общается твой

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

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

по Object.keys?

Object.keys(result.data.data)[0] вот так получаю первый пришедший ID, а как бы красиво упростить это?

мне нужно знать пришел ли хоть один id

по Object.keys?

Object.keys(result.data.data).length так норм?

Object.keys(result.data.data).length>0

?

Object.keys(result.data.data).length>0

вот точно уже сам придумал. Спасибо ?

result.data.data.length ?

Зач обжект кийс

Б

Хотя не не а

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

о каких эвентах речь? как о подходе к архитектуре или о nodejs events?

о каких эвентах речь? как о подходе к архитектуре или о nodejs events?

первое

никогда не видел таких систем. а вы?

каких именно?

где в основе работы некие эвенты, на которые кто хочет подписывается

https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%B1%D1%8B%D1%82%D0%B8%D0%B9%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%B0%D1%8F_%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0

эхххх еда

где в основе работы некие эвенты, на которые кто хочет подписывается

да, видел много раз

https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%B1%D1%8B%D1%82%D0%B8%D0%B9%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%B0%D1%8F_%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0

Андрей говорит о микросервисах на базе эвентов (как я понимаю)

а в чём разница?

EDA - это архитектура монолита. в ноде для этого все есть

слушайте. elasticsearch-js, сам сервак за http авторизацией, конфиг корректный, пологировал, в сам запрос заголовок Authorization попадает, ключ корректный, но сервак отвечает 401. при этом из postman/curl/браузера работает. в чем подводный камень?

шта?

а очереди это что по твоему?

очереди - это не архитектура

?

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

очередь - это инструмент

EDA - это архитектура монолита. в ноде для этого все есть

ну сейчас очень многие пишут в облаке. не знаю уж как в России, в Европе это практически стандарт для любых новых корпоративных разработок. а в облаке всё приспособлено для микросервисов и следующей их ступени - функций. Микросервисы и функции опять же в моде последние пару лет, так что их часто используют. А для того чтобы их связывать друг с другом, прямой вызов обычно недостаточно гибок, поэтому чаще всего через очередь либо event grid.

Я много раз видел и принимал участие в разработке систем где активно используется event grid в сочетании с микросервисами и функциями

ну сейчас очень многие пишут в облаке. не знаю уж как в России, в Европе это практически стандарт для любых новых корпоративных разработок. а в облаке всё приспособлено для микросервисов и следующей их ступени - функций. Микросервисы и функции опять же в моде последние пару лет, так что их часто используют. А для того чтобы их связывать друг с другом, прямой вызов обычно недостаточно гибок, поэтому чаще всего через очередь либо event grid.

вы легко можете посмотреть всех подписанных на любое событие, в таком случае. будь то aws sqs, aws sns или просто rabbitmq

ну я объяснял вверху, таких подписок может быть несколько сотен, и они не указывают на конкретный код, нужно еще потом открыть соответственный проект, endpoint найти и т.д.

это очень медленно

плохая архитектура значит

интересный вывод)

meh

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

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

просто это более-менее большой проект

такие проекты уже не рефакторятся :)

первый пример успешного рефакторинга, который приходит в голову - netflix. вряд ли ваш проект больше

ERROR: S client not available

первый пример успешного рефакторинга, который приходит в голову - netflix. вряд ли ваш проект больше

ну нетфликс это продукт у которого дохрена денег. многие большие продукты делали большие рефакторинги, причем у них были для этого весомые предпосылки. увеличение трафика и т.д. но и затраты на такие рефакторинги были сумасшедшие. я работаю в корпоративной сфере, там ситуация другая. увеличения трафика не предвидится, упор на бизнес функционал, ну и также нет бесконечного потока бабла от Netflix подписчиков, чтобы можно было 3+ лет сидеть рефакторить...

и я убежден что таких продуктов как нетфликс, единицы

и я убежден что таких продуктов как нетфликс, единицы

Хех

Понятно. Зато терпение тренируется, пока разбираешься.

и мне кажется 200 подписок это совсем не много в мире микросервисов, а уж тем более в функциях. самих микросервисов куча, вот и эвентов тоже куча.

вот один из текущих проектов, посмотрел ради интереса - 30 функций и 40 подписок в общем event grid-е. И это всего лишь инфраструктурный проект, там event grid в основном выполняет транспортную функцию

и мне кажется 200 подписок это совсем не много в мире микросервисов, а уж тем более в функциях. самих микросервисов куча, вот и эвентов тоже куча.

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

вот именно, кто как разобьёт, кто как придумает какие должны быть подписки. так что 200 это я считаю не очень много

если честно уже даже в 40 ногу сломишь

если честно уже даже в 40 ногу сломишь

Вообще, странно. Эвент грид плоский? Как таблица?

это в Azure, я хз насчет aws

заменяете ли вы switch на обьект?

Вообще, странно. Эвент грид плоский? Как таблица?

да, как таблица

да, как таблица

Понятно. представляю, насколько это неудобно переносить логику графа в таблицу

Может, вы не по назначению его используете

Я работал с aws sqs и rabbitmq. 40 сообщений с разными топиками (можно их и эвентами назвать) не проблема

Может, вы не по назначению его используете

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

и самое классное - это full-stack intellisense с этой точки зрения

Я работал с aws sqs и rabbitmq. 40 сообщений с разными топиками (можно их и эвентами назвать) не проблема

в очередях другая проблема - понять кто туда пушит ?

заменяете ли вы switch на обьект?

Да

Да

какие преймущества ты видиш?

в очередях другая проблема - понять кто туда пушит ?

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

какие преймущества ты видиш?

Отстутствие перебора всех условий

Я работал с aws sqs и rabbitmq. 40 сообщений с разными топиками (можно их и эвентами назвать) не проблема

и я не говорю что 40 подписок это проблема. просто лично мне неудобно когда нет возможности легкой навигации по коду. Нужно всего 2 вещи по сути: Go to definition и Find all references. Когда есть место где control flow куда-то уходит, и это место не покрыто двумя этими командами, это уже сильно замедляет процесс на мой взгляд.

Отстутствие перебора всех условий

Перебор все равно будет

какие преймущества ты видиш?

Меньше писать. Не надо case каждый раз писать

Перебор все равно будет

Разве? Мне казалось, взятие значения объекта по ключу это O(1)

там же хеш таблица

произодительность выше у обьекта, чем у switch case

я сейчас изучал тему, вот пункты, которые собрал: 1. производительность 2. дроби 3. возможность вызова в функциональном стиле: this.switch[case] 4. контекст 5. падения 6. let, const при создании переменной, не способность сделать return 7. процедурный поток выполнения 8. обязаность писать break, синтаксическая конструкция усложнена 9. обазательность сравнения ===, в случаях с регулярками возникают проблемы https://toddmotto.com/deprecating-the-switch-statement-for-object-literals/ https://medium.com/chrisburgin/rewriting-javascript-replacing-the-switch-statement-cfff707cf045 http://www.nicoespeon.com/en/2015/01/oop-revisited-switch-in-js/ https://stackoverflow.com/questions/3491094/problem-with-javascript-switch-statement

я подумал вы чисто про синтаксис

Разве? Мне казалось, взятие значения объекта по ключу это O(1)

а в switch идет перебор?