Думаю блюберд тоже поддерживает. Только зачем его использовать в 2018? ? Ты там что на node 0.10 пишешь?

Поддерживают

Думаю блюберд тоже поддерживает. Только зачем его использовать в 2018? ? Ты там что на node 0.10 пишешь?

1) вроде быстрее был когда я смотрел в последний раз 2) можно сразу всю либу скормить

Any может быть только в 1% случаев, все можно типизировать

Вот с этим согласен полностью. Иногда бывает что где то тайпинги отсутствуют, хотя и редко, но это решается простейшим образом в 99% случаев. Нужны лишь базовые знания ts чтобы подкорректировать тайпинги

Вот с этим согласен полностью. Иногда бывает что где то тайпинги отсутствуют, хотя и редко, но это решается простейшим образом в 99% случаев. Нужны лишь базовые знания ts чтобы подкорректировать тайпинги

?

1) вроде быстрее был когда я смотрел в последний раз 2) можно сразу всю либу скормить

Рано или поздно будет медленнее. Это ж блин c++ против js...

?

Рано или поздно будет медленнее. Это ж блин c++ против js...

Промисы в в8 давно переписали с жс на с/с++?

Я говорю рано или поздно, не в курсе о текущей ситуации

Любые популярные замены нейтив функций рано или поздно дохнут, потому что ребята на плюсах там подкручивают немного и опа, нейтив уже в 150 раз быстрее работает

ну рано или поздно вместо блуберба напишу свой промисификатор который будет юзать util

остальной код при этом не поменяется

https://palantir.github.io/tslint/rules/no-any/ - лучшее средство от any

ну рано или поздно вместо блуберба напишу свой промисификатор который будет юзать util

https://jsperf.com/promise-vs-bluebird сейчас вроде как одинаково по перфомансу...

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

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

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

+

а при 5-10 асинхронных реквестов, какой там смысл от bluebird, даже если б мы вернулись на пару лет назад когда native Promises были в пару раз медленнее... ну на 10 наносекунд бы код выполнялся быстрее?

и оно того стоит? тянуть дополнительную либу ради этого

Ребята, у кого high load проекты есть активные или были?

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

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

Ребята, у кого high load проекты есть активные или были?

Ты лучше вопрос сразу задавай

Кстати да, общение между микросервисами Rest Api не варик?

Кстати да, общение между микросервисами Rest Api не варик?

Почему не варик?

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

+

мда

Зависит от задач. Иногда и реста хватает. Иногда что-то сложнее надо

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

soa

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

Через общую шину кажется проще

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

синхронных вообще не должно там быть ты из какого мира дружище? то, что асинхронные реквесты не блокируют евент луп, никак не влияет на то, что они всё-таки требуют время на выполнение, и ты не вернешь response пока все нужные реквесты не выполнятся. скорость ответа не менее важный фактор чем throughput. если у тебя высокий throughput, но каждый реквест занимает по 2 секунды, это будет мега медленный сайт

Я редис юзал в свое время, там бонусом еще и паб-саб идёт простенький

синхронных вообще не должно там быть ты из какого мира дружище? то, что асинхронные реквесты не блокируют евент луп, никак не влияет на то, что они всё-таки требуют время на выполнение, и ты не вернешь response пока все нужные реквесты не выполнятся. скорость ответа не менее важный фактор чем throughput. если у тебя высокий throughput, но каждый реквест занимает по 2 секунды, это будет мега медленный сайт

Опять же, зависит от задач. Некоторые запросы и по несколько минут могут выполнятся.

Опять же, зависит от задач. Некоторые запросы и по несколько минут могут выполнятся.

я выше говорил, "для типичного бэкенда"

Зависит от задач. Иногда и реста хватает. Иногда что-то сложнее надо

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

синхронных вообще не должно там быть ты из какого мира дружище? то, что асинхронные реквесты не блокируют евент луп, никак не влияет на то, что они всё-таки требуют время на выполнение, и ты не вернешь response пока все нужные реквесты не выполнятся. скорость ответа не менее важный фактор чем throughput. если у тебя высокий throughput, но каждый реквест занимает по 2 секунды, это будет мега медленный сайт

Без синхронного кода никак не обойтись

soa

Прочту про него сейчас

синхронных вообще не должно там быть ты из какого мира дружище? то, что асинхронные реквесты не блокируют евент луп, никак не влияет на то, что они всё-таки требуют время на выполнение, и ты не вернешь response пока все нужные реквесты не выполнятся. скорость ответа не менее важный фактор чем throughput. если у тебя высокий throughput, но каждый реквест занимает по 2 секунды, это будет мега медленный сайт

в типичном бекенде не должны асинки по 2 секунды выполняться

Через общую шину кажется проще

Общую шину?

Опять же, зависит от задач. Некоторые запросы и по несколько минут могут выполнятся.

в консольных утилитах можно и синхронный io использовать. для этого его там и оставили

Общую шину?

Очередь какую нибудь возьми

в типичном бекенде не должны асинки по 2 секунды выполняться

вот и я про то же

А обмен посредством чего будет происходить?

Без синхронного кода никак не обойтись

под синхронным он имел в виду типа fs.fileReadSync

в типичном бекенде не должны асинки по 2 секунды выполняться

У меня типичный бекенд. Ну наверное. Там есть запросы выполняются по несколько минут. Да так и задумывалось. Всех всё устраивает

А обмен посредством чего будет происходить?

RabbitMQ, Kafka и тд смотри, http только для небольших нагрузок

У меня типичный бекенд. Ну наверное. Там есть запросы выполняются по несколько минут. Да так и задумывалось. Всех всё устраивает

и пользователь это ждёт? честно? ?

А обмен посредством чего будет происходить?

ну в случае редиса это tcp/ip. плюс такого подхода, что шина ничего не знает про сервисы, и сервисы ничего не знают друг о друге

RabbitMQ разве не для общения между VDS?

RabbitMQ, Kafka и тд смотри, http только для небольших нагрузок

зачастую это пушка по воробьям

и пользователь это ждёт? честно? ?

Ждёт. Честно. 100 мегабайтный csv за секунду увы построить не выйдет

Минус соот-но в том, что есть единая точка отказа

Соотна?

зачастую это пушка по воробьям

очевидно

ну в случае редиса это tcp/ip. плюс такого подхода, что шина ничего не знает про сервисы, и сервисы ничего не знают друг о друге

Хмм

RabbitMQ разве не для общения между VDS?

в телеге игра есть известная, полностью на кроле выдается апи

Возьми редис поковыряй, он клёвый

Редис потянет high load?

Он мега-быстрый

Редис потянет high load?

да, че ему? норм инстанс для редиса и всё агонь

так вот удобен ли mq пользователям? - нет нужна ли такая скорость? - нет так ли он быстр? - нет

по 10 минут калькуляции битв происходят, факт

Ого

ERROR: S client not available

так вот удобен ли mq пользователям? - нет нужна ли такая скорость? - нет так ли он быстр? - нет

альтернативы или по архитектуре совсем другие, или по факту ещё более кривые

так вот удобен ли mq пользователям? - нет нужна ли такая скорость? - нет так ли он быстр? - нет

эм ну как бы зависит от задачи для общения между сервисами особенно когда нужен брокер сложнее обычного паб/саб все ок

Ребята, последний вопрос и я погружусь в глубокую работу))

имхо это фанатизм, но, пожалуйста, не делайте юзерапи на mq

эм ну как бы зависит от задачи для общения между сервисами особенно когда нужен брокер сложнее обычного паб/саб все ок

вот это можно самому реализовать оч просто на сокетах

можете подсказать как с npm-run-all сделать sleep/delay для одного скрипта?

Ждёт. Честно. 100 мегабайтный csv за секунду увы построить не выйдет

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

вот это можно самому реализовать оч просто на сокетах

как и большинство других задач

+ поддерживать и контролировать проще, так что тут я за велик

Ребята, последний вопрос и я погружусь в глубокую работу))

Каждый автономный микросервис сам сможет сессию вскрыть?

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

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

Или обязательно слать на Auth Service для расшифровки?

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

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

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

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

У сервера будет Rest Api для клиента?

У сервера будет Rest Api для клиента?

эмм … не понял вопроса

У меня общение между клиентом и сервером происходит посредством Rest Api

У меня общение между клиентом и сервером происходит посредством Rest Api

апи гэтэвэй это называется

если так - то тебе рэббит вообще не нужен

Redis идеально значит подходит?)

Redis идеально значит подходит?)

как кэй-вэлью сторедж или для кеширования да

А при использовании Rabbi'a, общение между клиентом и сервером как работает?

Раббит же между серверами

А при использовании Rabbi'a, общение между клиентом и сервером как работает?

ampq протокол. типа соккета

Аа

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

Я планируют редис для общения юзать

Я правильно понял, что есть желание заюзать рэдис как БД?

Хранить я в Монго буду)

Я правильно понял, что есть желание заюзать рэдис как БД?

БД?