хорошо, пойду допишу сервер на knex, выглядит как многообещающе :)

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

#оффтоп Кто нибудь покупал ардуино? Как оно вам?

Для наколенных поделок вполне удобно.

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

Спасибо за замечание :)

кто использует supertest, там можно сделать что-то типа мидлвара? хочу проверять, что в каждом ответе с кодом >= 400 есть определенное поле

#оффтоп Кто нибудь покупал ардуино? Как оно вам?

90% людей кто покупал чуть поигрался и валяется) вообще интересно но надо под какой то конкретный проект иначе быстро надоедает игрушка

Лол, да. У меня валяется ардуино, пяток esp'шек и коробка всяких реле, датчиков, сдвиговых регистров и прочей мелочи. Ждут своего звёздного часа. Или помойки, как повезёт :-)

у меня 2 ящика забитых всякой электроникой, моторами, колесами ИТД )))

тоже чет приуныли и ждут чего то

Собери ОБЧР :-)

кстати NodeMCU прикольней чем ардуинка, вайфай из коробки

для новичка лучше зайдет

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

90% людей кто покупал чуть поигрался и валяется) вообще интересно но надо под какой то конкретный проект иначе быстро надоедает игрушка

Хех, проект есть)

Кто то умеет для 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" } ] } }

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

вот-вот

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

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

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

Может я его просто не для тех задач использовал

я не представляю как я жил до докера

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

но он как бы и не везде нужен

Всем привет. Кто знает как в winston можно поменять стандартный цвет для debug записей ? Сейчас цвет дебаг записей синий. А нужен оранжевый.

а почему именно оранжевый?....о_О

просто интересно

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

nodemon падучий очень, в любой момент при перезапуске приложения. Однозначно не стоит в prod. Если хочется чуть стабильнее, то pm2, у него есть свой вотчер изменений (сам не пробовал).

nodemon падучий очень, в любой момент при перезапуске приложения. Однозначно не стоит в prod. Если хочется чуть стабильнее, то pm2, у него есть свой вотчер изменений (сам не пробовал).

не юзаю никакие вотчеры изменений в проде

pm2 startOrRestart process.config.js и хватит

а почему именно оранжевый?....о_О

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