Уважаемые читатели! Как вы организуете выполнение тяжёлых вычислений в Node.js-приложениях?
Я использую модуль cluster для создания пула воркеров и MySQL для организации очереди задач. Я когда-то даже писал статью об этом. Но использование модуля worker_threads выглядит многообещающим.
Почему в сравнении нет bitbucket? Для команд до 5-ти человек приватные проекты там бесплатны, стоимость ниже чем на github, да и все основные фичи есть.
> Создается впечатление, что в вашей команде просто не хватает экспертизы по работе с очередями.
Экспертиза по работе с очередями есть, нужна тесная интеграция работы с постановленными задачами в самом проекте. Про гибридное решение уже писал выше в комментарии.
> Не ясно почему написан boirplate, а не генератор
Генераторы не используем. Не думаю что это минус.
> Зачем использовать bluebird, когда в требованиях packege.json 4-ая нода с нативными промисами?
Еще начали использовать обертки над промисами с версии 0.10.x. Ипользовали Q, перешли к bluebird. У blurbid есть много «плюшек», таких как promisifyAll, delay и т.д. Здесь они пока не используются, но могут быть использованы в будущем.
> Странный код стайл. Подключите eslint
Что вас смутило в код стайле? eslint подключу обязательно.
> Если вы выкладываете в opensourse то следите за актуальность readme.md Это важнее чем статья на хабре.
До README.md еще не добрался. Сначала решил выложить статью на хабре.
> изменяем переменную из окружения?
Пример взят из документации log4js https://github.com/nomiddlename/log4js-node#configuration
Можно конечно использовать метод configure, согласен. Нужно изменить.
> куча then и не одного catch?
Все верно, результат метода обрабатывается в базовом воркере. Это описано в статье.
> Тестов нет. Travis и TDD
Про тесты я так же в статье писал, что это в планах.
> И на последок главный вопрос, а что вы анализировали из готовых решений в opensource?
Как я уже писал выше, реализация эволюционировала из проектов, над которыми мы работали вот уже более 5-ти лет. Соответственно сформировались свои требования и были отработаны многие моменты. Так что изыскания я не проводил.
Впрочем, ваш бойлерплейт скорее не про демонизацию, а про очередь задач и воркеров (а демонизировать можно и с помощью pm2, отдав ему работу по деплою, горячей перезагрузке и мониторингу нагрузки).
Вы правы, демонизация это только часть бойлерплейта. Упор сделан на обработке задач. Нужно подумать над интеграцией pm2 в проект.
Потому таки неясно, почему вы не выбрали архитектуру с шиной типа MQ
Одно из исходных условий — мониторинг и управление задачами из самого приложения (куда интегрируется этот проект). Соответственно хранение задач в базе данных — лучший, если не единственный, выбор. Конечно можно сделать гибридное решение, когда задачи находятся в базе данных, а нотификация о поступлении задач проходит через MQ. Но в этом случае появляется еще одна зависимость и все приходится дополнительно налаживать синхронизацию задач между базой и MQ.
Т.е., точка отказа таким решением не устраняется всё равно, а воркеры получаются неабстрагированными от хранилища задач.
На данном уровне отказоустойчивость базы данных принципиально не рассматривается. Если база упала, то падает и весь проект. Отказоустойчивость базы данных настраивается отдельно.
Спасибо, обязательно посмотрю. Однако свой велосипед не просто так появился. Он эволюционировал из множества реализованных проектов и тесно связан с разрабатываемыми проектами.
В gmail в календарь аналогично приходят напоминания/мероприятия от Booking.com и Островок. Я так понимаю приходят эти события обычными вложениями в определенном формате, который понимают все современные почтовые клиенты (в том числе и Thunderbird). Так что это не заслуга (по крайне мере не киллер-фича) Blackberry.
Так ни кон же не говорит что это именно те поджигатели. Просто упомянули фамилии людей, похожих на поджигателей, которых нашёл сервис. Чисто технически презумпция невиновности не нарушена. Ни кто не говорит что именно они сделали поджег.
Я использую модуль cluster для создания пула воркеров и MySQL для организации очереди задач. Я когда-то даже писал статью об этом. Но использование модуля worker_threads выглядит многообещающим.
Переводите, пожалуйста, правильно:
«Уходя из дома с утра, не забудьте взять свой пиджак»
> Создается впечатление, что в вашей команде просто не хватает экспертизы по работе с очередями.
Экспертиза по работе с очередями есть, нужна тесная интеграция работы с постановленными задачами в самом проекте. Про гибридное решение уже писал выше в комментарии.
> Не ясно почему написан boirplate, а не генератор
Генераторы не используем. Не думаю что это минус.
> Зачем использовать bluebird, когда в требованиях packege.json 4-ая нода с нативными промисами?
Еще начали использовать обертки над промисами с версии 0.10.x. Ипользовали Q, перешли к bluebird. У blurbid есть много «плюшек», таких как promisifyAll, delay и т.д. Здесь они пока не используются, но могут быть использованы в будущем.
> Странный код стайл. Подключите eslint
Что вас смутило в код стайле? eslint подключу обязательно.
> Если вы выкладываете в opensourse то следите за актуальность readme.md Это важнее чем статья на хабре.
До README.md еще не добрался. Сначала решил выложить статью на хабре.
> изменяем переменную из окружения?
Пример взят из документации log4js https://github.com/nomiddlename/log4js-node#configuration
Можно конечно использовать метод configure, согласен. Нужно изменить.
> куча then и не одного catch?
Все верно, результат метода обрабатывается в базовом воркере. Это описано в статье.
> Тестов нет. Travis и TDD
Про тесты я так же в статье писал, что это в планах.
> И на последок главный вопрос, а что вы анализировали из готовых решений в opensource?
Как я уже писал выше, реализация эволюционировала из проектов, над которыми мы работали вот уже более 5-ти лет. Соответственно сформировались свои требования и были отработаны многие моменты. Так что изыскания я не проводил.
Вы правы, демонизация это только часть бойлерплейта. Упор сделан на обработке задач. Нужно подумать над интеграцией pm2 в проект.
Одно из исходных условий — мониторинг и управление задачами из самого приложения (куда интегрируется этот проект). Соответственно хранение задач в базе данных — лучший, если не единственный, выбор. Конечно можно сделать гибридное решение, когда задачи находятся в базе данных, а нотификация о поступлении задач проходит через MQ. Но в этом случае появляется еще одна зависимость и все приходится дополнительно налаживать синхронизацию задач между базой и MQ.
На данном уровне отказоустойчивость базы данных принципиально не рассматривается. Если база упала, то падает и весь проект. Отказоустойчивость базы данных настраивается отдельно.