но это все приедет вероятно в nginx, поэтому это временные все решения на фоне нехватки такого в общепринятых инструментах

да ну из nginx'а нулевой балансер ( надо докручивать все модулями слава китайцам

да ну из nginx'а нулевой балансер ( надо докручивать все модулями слава китайцам

а из чего хороший балансер?

надежный и быстрый чтобы

У меня основное требование к балансеру сейчас уметь про хелсчекать и понять что что-то умерло плюс чтобы можно было по нормально раскатывать изменения

что в целом решает кубернетес/номад. но чот сложно

и сыро

но gobetween идеей exec мне очень понравился

написать bash скриптик который сам все прочекает

весьма ок

но деплоить еще и этот скрипт и мейнтейнить чот лень (

что в целом решает кубернетес/номад. но чот сложно

ну так они не для этого

У меня основное требование к балансеру сейчас уметь про хелсчекать и понять что что-то умерло плюс чтобы можно было по нормально раскатывать изменения

proxy from to... { policy random | least_conn | round_robin | first | ip_hash | uri_hash fail_timeout duration max_fails integer max_conns integer try_duration duration try_interval duration health_check path health_check_port port health_check_interval interval_duration health_check_timeout timeout_duration header_upstream name value header_downstream name value keepalive number without prefix except ignored_paths... upstream to insecure_skip_verify preset }

caddy умеет health_check свои делать

но gobetween идеей exec мне очень понравился

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

подскажите, как на ноде бичмарки своего кода(модуля) проводить?

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

ну это первому отвечает но с этим и nginx справляется

и вот gobetween не поддерживает проверку по коду, если сервис ответил это не значит что он адекватен, это не микросервисно совсем, вот хэлсы у caddy лучше сделаны точно

traefik вроде тоже не умеет код хэлсов, вот тебе и балансеры

подскажите, как на ноде бичмарки своего кода(модуля) проводить?

есть отличный benchmarkjs

Aleksandr помнишь - я написал простую ф-цию в 20 строк, для вывода даты по шаблону. Мы спорили по поводу бичмарков, сейчас вывел милисекунды в цикле через свою ф-цию

Aleksandr помнишь - я написал простую ф-цию в 20 строк, для вывода даты по шаблону. Мы спорили по поводу бичмарков, сейчас вывел милисекунды в цикле через свою ф-цию

что-то помню, а что это за числа?

миллисекунды

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

мило выглядит

дай ссылку на репо

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

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

по сравнению с кем? сравни запись через console простой строки и строки с датой

по сравнению с кем? сравни запись через console простой строки и строки с датой

чет не понял. -_-

чет не понял. -_-

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

по сравнению с кем? сравни запись через console простой строки и строки с датой

эм лол дату же откуда-то брать надо

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

понятное дело будет НО такая, что ей можно пренебречь

понятное дело будет НО такая, что ей можно пренебречь

вот что-то не уверен

вот что-то не уверен

лол если тебе надо написать дату где-то, ты что будешь делать?

лол если тебе надо написать дату где-то, ты что будешь делать?

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

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

на вопрос ответь просто

суть то не изменилась

на вопрос ответь просто

на какой?

да и date-template скорее про "удобный+быстрый" способ

и минимальный)

на какой?

Если тебе надо напечатать форматированную дату, что ты будешь делать?

Если тебе надо напечатать форматированную дату, что ты будешь делать?

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

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

Не о логгерах речь А если у тебя 15 языков в системе, и под каждый язык свой формат даты?

я предпочту иметь что-то протестированное и уже рабочее, чем тратить время на написание своего

Не о логгерах речь А если у тебя 15 языков в системе, и под каждый язык свой формат даты?

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

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

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

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

если бы каждый логгер писал своё решение на каждый чих то логгеры были бы серьезной проблемой

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

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

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

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

короче чувак хейтит готовые решения

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

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

короче чувак хейтит готовые решения

нет, конечно, можно почитать что я говорю прежде чем придумывать

нет, конечно, можно почитать что я говорю прежде чем придумывать

да ну, ты что. Зачем?)))

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

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

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

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

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

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

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

согласен

непонятно о чем спор

вот эпичный пример почему я всегда использую console напрямую без всяких популярных решений $ node benchmark/logging.js console.info x 1,459,530 ops/sec ±0.78% (88 runs sampled) rufus.info x 201,119 ops/sec ±0.62% (91 runs sampled) winston.info x 65,377 ops/sec ±1.05% (80 runs sampled) intel.info x 59,193 ops/sec ±1.13% (97 runs sampled) bunyan.info x 82,040 ops/sec ±0.68% (100 runs sampled) log4js.info x 45,273 ops/sec ±2.64% (83 runs sampled) Fastest is console.info мне от логгера нужно очень немного, чтобы он космически быстро писал нужные мне строки в консоль без накладок на ненужное мне форматирование, выходит примерно в 10 раз быстрее популярных логгеров

traefik вроде тоже не умеет код хэлсов, вот тебе и балансеры

Всмысле? ты хочешь в случае хорошего отвечать чем-то отличным от 200?

вот эпичный пример почему я всегда использую console напрямую без всяких популярных решений $ node benchmark/logging.js console.info x 1,459,530 ops/sec ±0.78% (88 runs sampled) rufus.info x 201,119 ops/sec ±0.62% (91 runs sampled) winston.info x 65,377 ops/sec ±1.05% (80 runs sampled) intel.info x 59,193 ops/sec ±1.13% (97 runs sampled) bunyan.info x 82,040 ops/sec ±0.68% (100 runs sampled) log4js.info x 45,273 ops/sec ±2.64% (83 runs sampled) Fastest is console.info мне от логгера нужно очень немного, чтобы он космически быстро писал нужные мне строки в консоль без накладок на ненужное мне форматирование, выходит примерно в 10 раз быстрее популярных логгеров

они просто хуево написаны. это вообщем-то не проблема логеров а проблема программистов

Всмысле? ты хочешь в случае хорошего отвечать чем-то отличным от 200?

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

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

ну хз от ручки микросервиса я ожидаю что он либо 200 ответит либо ошибкой

очень страно было бы в случае редиректа

О_о

ERROR: S client not available

Пока писал, в голову пришло несколько решений, но пока пути сверяются разбиением по "/" и сравнением по кускам. Кода получилось немного больше, чем ожидал. Но это в основном из-за использования for i

а регулярки поддерживаешь? :)

вот эпичный пример почему я всегда использую console напрямую без всяких популярных решений $ node benchmark/logging.js console.info x 1,459,530 ops/sec ±0.78% (88 runs sampled) rufus.info x 201,119 ops/sec ±0.62% (91 runs sampled) winston.info x 65,377 ops/sec ±1.05% (80 runs sampled) intel.info x 59,193 ops/sec ±1.13% (97 runs sampled) bunyan.info x 82,040 ops/sec ±0.68% (100 runs sampled) log4js.info x 45,273 ops/sec ±2.64% (83 runs sampled) Fastest is console.info мне от логгера нужно очень немного, чтобы он космически быстро писал нужные мне строки в консоль без накладок на ненужное мне форматирование, выходит примерно в 10 раз быстрее популярных логгеров

А есть исходник benchmark/logging.js?

ну хз от ручки микросервиса я ожидаю что он либо 200 ответит либо ошибкой

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

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

ну ответь любым не 200 какие проблемы?

вот эпичный пример почему я всегда использую console напрямую без всяких популярных решений $ node benchmark/logging.js console.info x 1,459,530 ops/sec ±0.78% (88 runs sampled) rufus.info x 201,119 ops/sec ±0.62% (91 runs sampled) winston.info x 65,377 ops/sec ±1.05% (80 runs sampled) intel.info x 59,193 ops/sec ±1.13% (97 runs sampled) bunyan.info x 82,040 ops/sec ±0.68% (100 runs sampled) log4js.info x 45,273 ops/sec ±2.64% (83 runs sampled) Fastest is console.info мне от логгера нужно очень немного, чтобы он космически быстро писал нужные мне строки в консоль без накладок на ненужное мне форматирование, выходит примерно в 10 раз быстрее популярных логгеров

А если группировать и выдавать пачками то можно вообще быстро сделать

ну ответь любым не 200 какие проблемы?

ну я так я и делаю, но понимает код из списка обсуждаемых только caddy

ну traefik

только 200 считает валидным

ну хз от ручки микросервиса я ожидаю что он либо 200 ответит либо ошибкой

А 201 тоже плохо?

Да

Да

Лол. Бред

А есть исходник benchmark/logging.js?

это из пакета rufus, https://github.com/btd/rufus

Ну во всяком случае так следует из документации. Что в опенсурсе не всегда правда

А 201 тоже плохо?

обычно 2**, 3** считаются положительными а их логика уже избыточный смысл для балансера

обычно 2**, 3** считаются положительными а их логика уже избыточный смысл для балансера

Ну вот я так же считаю

Но если 200 это ок а 201 нет Это уже маразм

я очень сомневаюсь что ручка health в удачном состояние должна вернуть что-то кроме 200

у ручки health одно назначение сказать что сервис жив

это бинарная опция в целом

это бинарная опция в целом

В общем да. Иногда инфу несёт с собой

я очень сомневаюсь что ручка health в удачном состояние должна вернуть что-то кроме 200

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

ты же ответив 204 не сообщил явно об ошибке, это вообще норм ответ

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

204 даже предпочтительнее 200 по логике хэлса

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

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

ребята, привет пишу первое приложение на ноде помогите, пожалуйста разобраться с ассоциациями(sequelize + postgress) Есть моделька Card var Card = sequelize.define('Card', { name: { allowNull: false, type: DataTypes.STRING, }, }) Есть моделька Partnership var Partnership = sequelize.define('Partnership', { comment: { type: DataTypes.TEXT }, }) Задача связывать между собой Card через Partnership. Есть такие связи Card.belongsToMany(models.Partnership, { through: 'CardPartnership' }) Partnership.belongsToMany(models.Card, { through: 'CardPartnership' }) Создание Partnership const createdBy = ctx.request.body.fields.createdBy const acceptedBy = ctx.request.body.fields.acceptedBy const partnership = await models.Partnership.create({ comment: ctx.request.body.fields.comment, createdBy: createdBy, acceptedBy: acceptedBy, }) await models.Card.findAll({ where: { id:[createdBy, acceptedBy] } }).then((cards) => cards.forEach((card) => card.addPartnerships(partnership))) Если хочется получить карточку со всеми партнерами const card = await models.Card.find({ where: { id: cardId }, include: [{ model: models.Partnership, through: { where: { CardId: cardId } }, include: [{ model: models.Card, where: { id: { $not: cardId } } }] }] }) Это работает. Но хочется услышать насколько это правильная механика) Может можно проще)

ребята, привет пишу первое приложение на ноде помогите, пожалуйста разобраться с ассоциациями(sequelize + postgress) Есть моделька Card var Card = sequelize.define('Card', { name: { allowNull: false, type: DataTypes.STRING, }, }) Есть моделька Partnership var Partnership = sequelize.define('Partnership', { comment: { type: DataTypes.TEXT }, }) Задача связывать между собой Card через Partnership. Есть такие связи Card.belongsToMany(models.Partnership, { through: 'CardPartnership' }) Partnership.belongsToMany(models.Card, { through: 'CardPartnership' }) Создание Partnership const createdBy = ctx.request.body.fields.createdBy const acceptedBy = ctx.request.body.fields.acceptedBy const partnership = await models.Partnership.create({ comment: ctx.request.body.fields.comment, createdBy: createdBy, acceptedBy: acceptedBy, }) await models.Card.findAll({ where: { id:[createdBy, acceptedBy] } }).then((cards) => cards.forEach((card) => card.addPartnerships(partnership))) Если хочется получить карточку со всеми партнерами const card = await models.Card.find({ where: { id: cardId }, include: [{ model: models.Partnership, through: { where: { CardId: cardId } }, include: [{ model: models.Card, where: { id: { $not: cardId } } }] }] }) Это работает. Но хочется услышать насколько это правильная механика) Может можно проще)

gist.github.com для кого создан?

Ну вот епт

Хоть бы в кавыки взял

gist.github.com для кого создан?

ссори, сек

ну типа помимо model, through я пользуюсь association. Ты ассоциацию к примеру в статическую переменную сохраняешь и дальше ее в инклюдах используешь

http://docs.sequelizejs.com/manual/tutorial/associations.html const Creator = Product.belongsTo(User, {as: 'creator'}); return Product.create({ title: 'Chair', creator: { first_name: 'Matt', last_name: 'Hansen' } }, { include: [ Creator ] });