Преди да добавите колона за статус: планиране на публикации без cron задача

Дата на публикуване, не нов статус

Заявката беше обикновена: редактор да може да публикува статия на бъдеща дата. Очевидното решение е също толкова обикновено: да се добави статус "планирана" и задача, която прави проверка всяка минута и превключва статуса при настъпване на датата. Освен това е необходимо да се добави административен екран за публикациите с новото състояние, обновление на всяка заявка към базата, която променя старите два статуса.

Докато разработвахме собствения си сайт, в Arc AI пуснахме планираните публикации без нов статус, без нова колона, без задача.

Скритата цена на колоната за статус

Да има трети статус изглежда евтино, докато не прецените къде трябва да се проверява: страницата на статията, на блога, емисията, картата на сайта, административните филтри, всеки тест за видимост. Пропуснете едно място, и планираната ви публикация или изтича по-рано на забравена страница, или изобщо не се появява.

После идва задачата. Фонов процес, повишаващ планирани публикации до публикувани, звучи безобидно, докато не се провали безшумно: лош деплой, задръстена опашка, заспал сървър, и никой не забелязва, докато някой не попита защо съобщението му не се публикува навреме. При SQLite разширяването на позволените стойности на полето за статус обикновено означава преизграждане на цялата таблица, а не бърза промяна. Една "малка" функционалност се превръща в миграция, нов начин за провал и утроена площ за тестване.

Какво всъщност означава "планирано"

Планирано просто означава публикувано, с дата, която още не е настъпила. Публичното правило за показване на статия вече стоеше по този начин: видима, когато е публикувана, а датата е сега или по-рано. Не се налага нищо да се случва точно в момента, в който планирана публикация излиза, защото правилото вече го покрива. Етикетът "Планирано" и филтърът в административния екран се изчисляват от същите два факта, които вече се съхраняват: публикувано, дата в бъдещето.

Кое е точно и кое може да навакса

Някои части се обновяват мигновено, други наваксват по-късно. Страницата на статията е точна веднага щом настъпи датата. Списъчните страници на блога следват в рамките на минути, зад кратък кеш. RSS емисията може да изостане до час. Картата на сайта се обновява при нощен рестарт, в 02:00 UTC, или по-рано, ако нещо друго го задейства първо. Файлът llms.txt е най-бавен, може да отнеме до денонощие.

За блог това е разумен компромис. Лоша идея е за промяна на цена или правно уведомление, където "в рамките на час" не е достатъчно добре. Дали това забавяне е приемливо не е инженерно решение, то принадлежи на собственика на продукта и си струва да се уточни писмено, преди да се направи каквото и да е.

Предпазни механизми, не повече състояния

Активна, индексирана статия не може случайно да получи бъдеща дата, защото това тихо би свалило публична страница офлайн; интерфейсът изисква първо да я свалите. Запазването на публикация, която е само планирана, не задейства никое от публичните преизграждания, защото все още няма какво да види читателят.

Датата на публикуване, която се показва на читателите, е редактируема. Моментът, в който статията за пръв път стане публична, е отделен факт, записван веднъж и никога презаписван, и на него разчитат други части от сайта за историята на адресите. Това разделяне създава едно изключение: планирана публикация, изтрита преди датата ѝ на излизане, пак запазва адреса си, завинаги. В Arc AI решихме, че се случва достатъчно рядко, за да го оставим без допълнителен код за проверка.

Пет въпроса, които да зададете преди да продължите

• Може ли новото състояние да се изчисли от данни, които вече съхранявате?
• Кои странични ефекти наистина трябва да се случат в точно определен момент, и кои могат да изчакат?
• Колко време закъснение е позволено за всеки зависим резултат?
• Какво спира един редактор случайно да премести публична страница в бъдещето?
• Кои изключения са достатъчно редки и безобидни, за да ги приемете писмено, вместо да ги обработвате?

Попитайте кое вече знае отговора

Вместо да посягате към нов статус, флаг или cron задача, попитайте дали отговорът вече може да се изчисли от данни в базата, кой наистина се нуждае нещо да се случи в точната секунда и кой е добре да разбере няколко минути или ден по-късно.