Кто то умеет для webdriver io дампить сессию, а потом переиспользовать ее?

Ребят, подскажите как архитектурненько сделать. Есть модуль который работает с superagent'ом и шлет данные от микросервиса на другие сервисы через кролика. Проблема в том что кролик (именно он, сервисы все за ним, напрямую я к ним не обращаюсь и не планируется) может лечь. Пока что гипотетически. Я собираюсь под это дело впаять в сервис MQ на редиске. Вопрос - оставлять один модуль который шлет данные на кролика и впаять MQ прямо туда (назовем его условно client.js), или сделать под MQ отдельный модуль и общаться с ним через шину?

если что непонятно сформулировал, скажите - я поясню

а, пока писал, сходу возник другой вопрос - там еще ELK стэк, в LogStash тоже через именутый MQ все складывать для красоты картины?

Ребят, подскажите как архитектурненько сделать. Есть модуль который работает с superagent'ом и шлет данные от микросервиса на другие сервисы через кролика. Проблема в том что кролик (именно он, сервисы все за ним, напрямую я к ним не обращаюсь и не планируется) может лечь. Пока что гипотетически. Я собираюсь под это дело впаять в сервис MQ на редиске. Вопрос - оставлять один модуль который шлет данные на кролика и впаять MQ прямо туда (назовем его условно client.js), или сделать под MQ отдельный модуль и общаться с ним через шину?

Мутновато описано. Я правильно понял суть - ты хочешь между своим сервисом и MQ воткнуть дополнительную пррослойку а-ля circuit breaker, на случай того, что если ляжет MQ, то лег только он, а не вся система, и сервис продолжит общаться с посредником?

Ща поясню, почти

-> 1. какой-либо модуль в моем сервисе отправляет задачу на отправку в модуль в котором есть require('superagent') -> 2. Superagent отправляет это в RabbitMQ на другом хосте -> 3. Другой любой сервис принимает это

я хочу вкорячить между 1 и 2 свой локальный MQ

на случай если лёг Rabbit

модуль который собирает сообщения и делает прочую хрень и отправляет все с помощью суперагента - client.js

так понятнее?)

я б схемку нафигачил но долго

надо было наверное это написать еще - все модули общаются через pub/sub

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

да, все так - но вопрос в силе) стоит ли делать отдельный модуль чисто для работы с MQ или вкорячить MQ прям в client.js?

условно - require('bull') (bee/que/какой угодно mq пакет) прям в client.js и там всю логику или все таки отдельно*

вариант с вкорячиванием прямо в client.js сильно нарушает SRP... но блин отдельный модуль херачить чисто для MQ мне почему-то кажется оверхэдом

У тебя всё в одном файле?

по идее можно вообще без mq обойтись доплнительной, например, при недоступности ты складываешь сообщения в базу/кеш (самый простой вариант во встроенную, чтобы отдельно не запускат ьвсякие редисы), а как только коннект появился - достаешь их оттуда.

Базу тоже можно самому написать

У тебя всё в одном файле?

не, ты что)))) упаси боже

И tcp

ну так у меня MQ в редиску в любом случае все сливает, и в редиске стоит та опция чтоб все персистилось

ну и сливай это в редиску тогда, дополнительный сервис для этого городить, имхо, не стоит. просто доработать существующий и вынести в конфиг какую-нибудь настройку по вкл/выкл, подсистемы хранения сообщений при недоступности mq

ладно, по разному попробую

Вроде бы bull умеет накапливать очередь

Вопрос только насколько большой она может оказаться

Кто то умеет для webdriver io дампить сессию, а потом переиспользовать ее?

а зачем такое? это антипаттерн

народ, согласно 12 factor app нужно различные конфижные данные хранить в переменных окружения, какой тут best practice может быть? не пилить же их в package.json перед командами запуска

я в ENV запихал. про best practice тож послушаю, интересно

> народ, согласно 12 factor app нужно различные конфижные данные хранить в переменных окружения во первых, 12fa это не стандарт в целом - это лишь имплементация best practices от heroku заточеная под heroku то есть те же самые ENV... ну вроде бы и норм, но как-то прям в переменных... просто в heroku по другому нельзя :) во вторых, 12fa в целом неплох для сервера но тут зависит от того что и КАК ты деплоишь: кластер ли это kubernetes/swarm, локальное приложение на юникс-хостинге, или еще что

да хз, обычный nodejs (koa) сервер для АPI, про кластеризацию пока и мыслей нету

лично я (так, для инфы) обычно юзаю модуль https://www.npmjs.com/package/config в проекте что-нибудь типа config/default.js: module.exports = { someitem: 'qwe', someitem2: process.env.SOME_ITEM2 || 'default' } :)

смотри как у тебя развертывание происходит

какие-то переменные необходимые для сборки храни в переменных окружения, если что-то надо поменять уже в рантайме - делай config.json какой-нибудь например. ну... по крайней мере у меня так)

локально подсовываю .env в рут-директории, в продакшне https://github.com/deis/workflow (кубернетес-фигня), в тестах docker-compose

народ, согласно 12 factor app нужно различные конфижные данные хранить в переменных окружения, какой тут best practice может быть? не пилить же их в package.json перед командами запуска

многие используют такой подход - дефолтные настройки хранят в конфиге из репозитория, а динамические переопределяют из переменных, в общем случае это не налагает ограничений на структуру конфига например такой переменной MY_PREFIX_custom_list='[{"key1": "value1"}, {"key2": "value2"}]'перегружаются значения из конфига { "custom": { "list": [ { "key1": "value1" }, { "key2": "value2" } ] } }

ERROR: S client not available

собственно, я че зашел на этот замечательный канал (сори за оффтоп :): кто-нибудь играется с amqp ha кластерами и подключением к ним из под ноды? у меня куча вопросов почему все дрова amqp такие старые и не умеют файловер/рекавери нормально, и поиск того кто нашел ответы :)

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

тут многие спят прост

а nodemon можно и на продакшене использовать или не надо? Он какой то оверхед дает? В докере себе для разработки его прекрутил, стоит ли заморачиватся как то 2 версии делать для продакшена и разработки или и так сойдет?

а nodemon можно и на продакшене использовать или не надо? Он какой то оверхед дает? В докере себе для разработки его прекрутил, стоит ли заморачиватся как то 2 версии делать для продакшена и разработки или и так сойдет?

для продакшна есть пожирнее и популярнее вещи, как пм2

они тоже могут перезапустить упавшее

но ещё много чего

перезапустить упавшее звучит как аварийно передёрнуть:D

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

да для разработки вообще пофиг, бери что понравится

да для разработки вообще пофиг, бери что понравится

так он про использование в продакшне говорил

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

я запутался кароч(

я запутался. истина где-то там

вот-вот

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

Как вообще вам докер? Нравится?

Как то пробовал, мне чет не зашло