Какой эффективный способ отложенной публикации постов реализовать?
Привет.
Собираю небольшой API сервер на Ноде, Экспресс, Монго. Возник вопрос как лучше организовать отложенную публикацию?
Например, я создаю документ Article, и хочу чтобы он не сразу использовался приложением, а тогда когда я укажу.
Как лучше всего это сделать, чтобы не было лишних проверок, запросов, фильтрации и тд?
Первое что на уме - это указывать поле PublishAt и там указывать время, но ведь тогда серверу прийдется каждый пост проверять лишний раз перед тем как отдать это на клиент. А если таких постов 100 штук и посетителей 1000? Кеширование и тд вроде понятно, но как все изначально правильно реализовать?
ilovemaryjane, в вашем варианте описана полная выборка с последующей фильтрацией на серверной стороне. Правильно оставить выборку целиком на совести БД, это эффективный способ, поскольку выборка по такому условию очень простая и не создаст никаких проблем с производительностью.
Попробуйте провести замеры, чтобы в этом убедиться. Добавьте индекс для поля PublishAt.
Еще был предложен вариант с кроном, но заметьте, что там всё равно будет дополнительное условие для выборки, хоть и немного более простое, но добавляется необходимость в кроне и могут возникнуть проблемы в случае если по какой то причине крон не отработал.
Т.е. мне надо будет передавать значение времени в крон из Ноды? И крон потом в указанное время залезет в БД и изменит значение? Это довольно продвинутое использование, я такого еще не делал. Подскажите что почитать по этой теме
ilovemaryjane, не. в базу при сохранении статьи записывать isPublished=0, publishedAt=xxx, кроном с нужной периодичностью прост выбирать статьи с временем меньше текущего и атрибутом равным нулю.
Для отложенной публикации использовать крон, который будет в нужное время проставлять этот атрибут.
Нет, нет, нет, и еще раз нет.
Если что-то можно сделать без кронов и демонов - надо делать без них.
Я сейчас как раз работаю с проектом, где предыдущий бек размышлял таким же образом "а давай ка тут кроном сделаю", "а давайка тут демоном сделаю" - в итоге проект на ровном месте черезмерно переусложнен, в нем крон, демоны, которые плодят других демонов, и убивают сервер (забивается лимит процессов). И вообще после ухода старого программиста проект сдох, и тупо не запускается. А чтобы разобраться в чем ошибка - нужно распутать адовый клубок из кронов, демонов и говнокода которые между собой переплетены.
DevMan, какие-то слоупоки создают зоопарк технологий, а потом осознают, что сами не могут работать с тем, что наворотили, и увольняются.
На предыдущей работе даже опытные тим-лиды не могли удалить процедурки из MySQL, потому что они были так лихо вкручены в сложный проект предыдущими "любителями экзотики", что казалось бы удалили, переписали код чтобы работало без них, а потом бац, и то тут, то там начинает отваливаться функционал.
Мораль проста: если что-то можно сделать, не привнося в проект новую технологию - то это лучше сделать именно так.
HellWalk
1. использовать различные технологии - это нормально. если, конечно, руки правильно заточены.
2. использование одной технологии никак не защищает от говна.
3. крон - вообще не новая технология: планировщик есть в составе любой операционной системы искаропки.
мораль проста: если ты рукожоп, то хоть используй одну технологию, хоть десяток - итог предсказуем.
планировщик есть в составе любой операционной системы искаропки.
Да и демоны есть в любом линуксе. Давай их теперь пихать в каждый проект. Пусть у нас одни демоны php-код периодически правят, а другие - базу. Ну и на крон тоже какую-нибудь логику вынесем. Это же так весело, когда логика проекта разбита на десяток составляющих.
HellWalk, какие десятки составляющих? какие правки кода?
все что делает планировщик - запуск твоего кода в нужное время. если не уметь в логику, то используй планировщик или нет, будет весело.
Простой
Простой
Средний
