whats
С чего чего Вы взяли что в ноде 1 процесс? Можно отлично запускать пачку процессов ноды. По одному на ядро вполне оправдано.
Прямой селект из базы можно применять в ничтожном количестве случаев - вам должно быть пофиг на скорость реакции на событие, вам должно быть пофиг на контроль за обработкой данных, вам должно быть пофиг на распределение обработки между процессами - да на все пофиг по сути.
"Лишь бы работало"
Ruslan: "3 дня по 4 часа" хорошо когда в остальные 20 часов в день человек пьет чай с виски и думает в фоне о проблеме. А в ситуации когда он хреначит 8 часов по другом проекту а потом сидит и вспоминает что же он вчера делал по Вашему - это жесть, проверено опять же лично)
Ruslan: исключение когда можно иметь несколько заказчиков - когда работа связана с большим количеством мелких задач. (системное администрирование, оперативный менеджмент, какие то доработки etc). Тогда иметь несколько клиентов разумеется оправдано.
Ruslan: Я смотрю на ситуацию и как заказчик поскольку им являюсь сейчас, и как исполнитель поскольку им являлся раньше.
И заказчик, и исполнитель заинтересованы в том что бы закрыть любую работу максимально быстро и получить за неё исполнитель-деньги, заказчик-результат.
Соответственно ни как заказчик, ни как исполнитель не заинтересованы в том что бы исполнитель занимался одновременной работой по нескольким направлениям. Тем более что от этого страдает не только скорость, но и качество.
Ruslan: Если говорить про задачи уровня "нарисуй банер за 2 часа" - то тогда конечно да.
Нормальная проработка ux среднего сайта занимает 1-2 недели fulltime работы для первой итерации, потом какой то период согласований когда дизайнер может заняться чем то другим, потом еще одна итерация по правкам. Это в идеальном случае.
Точно так же как верстальщику могут приходить задачи уровня "подвинь блок вправо", а может приходить пак из 80 страниц.
whats: Но вообще мы сильно отклонились от вопроса автора. Он спрашивал не как уведомить юзера - а как узнать об обновлении базы данных. Мне все таки думается что если у автора в базу пишет его же приложение - он бы дошел до идеи вызвать событие внутри приложения)
whats: и Вы, и я - изрядно додумали вопрос автора, но я в своих додумках ушел возможно в сторону.
Возможно меня подвели кейсы из проектов которые я наблюдаю в последнее время - у нас приложения на node.js занимаются только вебсокетами и ничем другим.
Что именно автор имел в виду - мы наверное не узнаем пока автор не появится.
В случае если у человека единое приложение на node.js реализующее в том числе и вставку в базу - Ваш вариант за номером 1 бесспорно является правильным.
whats:
Спасибо за внимание к моей персоне, даже зачитался.
Я не сторонник какой то дикой каши технологий, у меня достаточно небольшой любимый стек и я искренне уверен что есть объективно задачи которые по моему опыту удобнее и быстрее выполнять определенным образом.
Далее отвечу по сути комментария:
Для доставки событий ничего лучше чем очереди пока не придумали.
Вы реально не понимаете разницы между запросами в базу и подпиской на событие очереди?
Начнем хотя бы с того маленького факта что в первом случае а) будет достаточно большой лаг обработки события, равный времени таймера запроса б) при росте количества воркеров будет расти количество запросов, что с вкупе с пунктом А дает пусть и не особо большую - но все равно абсолютно излюшнюю нагрузку на sql.
Идея с соединением на сокетах в целом лучше, но включая режим телепата - как правило логика которая пишет в базу все таки отделена от демона сокетов. Соответственно надо научить подключаться к нему, убеждаться что все хорошо, прописывать поведение когда демон мертв, думать что делать если демонов несколько итд итп, в общем изобретать кучу велосипедов которые отлично решаются с помощью любого из существующих серверов очередей. Не нравится Rabbit - возьмите Gearman, возьмите ZeroMQ. Но не надо писать велосипеды.
Артем: ну на мобильном устройстве не так уж и легко...
но я сейчас подумал - и понял что не понимаю смысла запрета такого.
сейчас мобильный интернет быстрый. если сотрудники захотят страдать херней - будут страдать херней через 3g/4g/lte. Wifi для этого не нужен вообще.
