Тот кто следит за БД, бьет по рукам нерадивых разрабов, пишет процедуры и помогает составлять запросы

и миграции прогоняет

whats the most lightware nodejs db?

Подскажите, кто нибудь сталкивался с задачей организации темы wp по аналогии с проектами frontendа? Сборка гальпом и организация папок Scr, Public и т.д?

есть кластер из node stateless серверов в докер контейнерах, нужно добавить daily tasks, какое решение по рекомендуете?

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

т.к докер образ у всех одинаковый

т.е как отдельный сервис?

нет AWS eb но примерно суть та же

нет AWS eb но примерно суть та же

не варик переносить эту логику на другой сервис

Так тебе нужно по крону задачу выполнять, либо по событию?

и там уже написанна куча кода для нее

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

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

То есть у тебя часть архитектуры вне swarm?

да нет, все в swarm, и там есть грубо говоря функция, которая содержит логику, часть логики должно быть переиспользованно для daily tasks, т.е если я просто создам отдельный сервис-скрипт с кроном, то там прийдется описывать эту логику заного

если есть сущность "комментарий", который может относиться к двум разных сущностям, то лучше сделать две сущности "комментарий"?

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

а структура данных у них разная? или только привязка разная?

а если кто-то дернет хук N раз? а если упадет сервер при выполнении задачи?

Но это же оверхед для этой задачи, не?

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

только привязка разная, а структура одинаковая

тогда на мой взгляд лучше сделать enumeration entity_type

аха, хорошо. Тогда получается comment(id, text, author_id, entity_type, ref_id) ?

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

Здравствуйте, я близок к получению офера, я сделал тестовое, но мне ответили "Нам не нравится стиль кода, мог бы переделать". Мог бы кто-то просмотреть бегло код и посоветовать какие улучшения можно сделать или посоветовать куда обратиться с подобной просьбой ссылка на гит: https://github.com/hodovanyuk/reimagined-spork

Здравствуйте, я близок к получению офера, я сделал тестовое, но мне ответили "Нам не нравится стиль кода, мог бы переделать". Мог бы кто-то просмотреть бегло код и посоветовать какие улучшения можно сделать или посоветовать куда обратиться с подобной просьбой ссылка на гит: https://github.com/hodovanyuk/reimagined-spork

а какой стиль используют они?

Здравствуйте, я близок к получению офера, я сделал тестовое, но мне ответили "Нам не нравится стиль кода, мог бы переделать". Мог бы кто-то просмотреть бегло код и посоветовать какие улучшения можно сделать или посоветовать куда обратиться с подобной просьбой ссылка на гит: https://github.com/hodovanyuk/reimagined-spork

Я думаю что существует общая практика node прложений которой я не знаю, больше опыта в front-end

смесь var и let

это не код-стайл, как и про const, код-стайл не меняет смысла кода, только его выражение

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