Ako spúšťať úlohy na pozadí vo webovej aplikácii: fronty, plánovače a cron

Ak chcete spúšťať úlohy na pozadí vo webovej aplikácii, najprv rozdeľte prácu na dva druhy. Spúšťané úlohy (odoslať uvítací e-mail, spracovať nahrávku) možno uložiť do fronty úloh, často ide o tabuľku v databáze, a spracuje ich worker s opakovaniami. Naplánované úlohy (nočný report, pripomienky každých 15 minút) potrebujú niečo, čo sa spúšťa podľa rozvrhu: funkciu cron na hostingu alebo externý plánovač, ktorý volá chránený endpoint vo vašej aplikácii. Úlohy vždy robte tak, aby sa dali bezpečne spustiť dvakrát, zaznamenávajte zlyhania a nikdy sa nespoliehajte na časovač vnútri servera, ktorý môže zaspať alebo sa reštartovať.

Tento návod vysvetľuje možnosti, kedy sa ktorá hodí a ako ich nastaviť s AI nástrojom na tvorbu aplikácií, aj na hostingoch, ktoré škálujú na nulu.

Čo sa počíta ako úloha na pozadí

Akákoľvek práca, ktorá je pomalá, nespoľahlivá alebo nie je potrebná pre okamžitú odpoveď používateľovi:

• Odosielanie e-mailov, upozornení a potvrdení
• Zmenšovanie obrázkov, prekódovanie videa, generovanie PDF
• Volanie pomalých API tretích strán vrátane AI modelov pri dlhých úlohách
• Import alebo synchronizácia dát z iného systému
• Nočné upratovanie, reporty a pripomienky

Keď sa to robí priamo v požiadavke, stránky sú pomalé a krehké: ak je poskytovateľ e-mailu nedostupný, registrácia používateľa zlyhá. Presunutie na pozadie znamená, že používateľ dostane okamžitú odpoveď a úlohu je možné zopakovať.

Možnosti

Neexistuje jedna správna odpoveď. Malá aplikácia zvyčajne potrebuje len databázovú frontu a externý plánovač.

Prečo hostingy, ktoré škálujú na nulu, menia obraz

Mnohé moderné hostingy uspávajú vašu aplikáciu, keď ju nikto nepoužíva, a prebudia ju pri ďalšej požiadavke. To šetrí peniaze, ale spiaci server nespúšťa žiadny kód: časovače sa nespúšťajú a workery nič nekontrolujú. Na týchto hostingoch sa naplánovaná práca musí spustiť príchodzou požiadavkou a najjednoduchším zdrojom takejto požiadavky je externý plánovač. Každé volanie prebudí aplikáciu (a často aj jej databázu), takže volanie každú minútu stojí viac ako každých 15 minút. Vyberte najpomalší rozvrh, ktorý splní potrebu.

Vzor 1: databázová fronta úloh

Pre spúšťané úlohy:

1. Vytvorte tabuľku jobs: typ, payload (JSON), stav (pending, running, done, failed), attempts, run_after, last_error, časové značky.
2. Keď sa niečo stane, vložte riadok úlohy v tej istej transakcii ako zmenu, ktorá ju spustila, aby uspeli alebo zlyhali spoločne.
3. Worker vyberie splatné úlohy, označí ich ako running, vykoná prácu a označí ich ako done.
4. Pri zlyhaní zvýšte attempts, nastavte run_after neskôr (napríklad 1, 5, potom 30 minút) a uložte chybu. Po maximálnom počte pokusov úlohu označte ako failed a upozornite niekoho.

Ak môže bežať viac workerov naraz, úlohy sa musia prevziať bezpečne. V Postgrese SELECT ... FOR UPDATE SKIP LOCKED umožní každému workeru prevziať iné riadky bez kolízie.

Čo spúšťa worker? Na serveri, ktorý beží stále, slučka v samostatnom procese. Na hostingu, ktorý škáluje na nulu, môže naplánovaný endpoint zo vzoru 2 pri každom volaní spracovať dávku splatných úloh.

Vzor 2: externý plánovač volajúci vašu aplikáciu

Pre naplánované úlohy:

1. Pridajte endpoint, napríklad POST /api/cron/send-reminders.
2. Chráňte ho: vyžadujte tajný token v hlavičke, uložený ako tajomstvo na oboch stranách, a odmietnite všetko ostatné.
3. Urobte ho idempotentným: spustenie dvakrát v tej istej minúte nesmie poslať dve pripomienky. Zaznamenajte, čo sa odoslalo.
4. Každé volanie udržujte krátke: spracujte dávku (napríklad 100 položiek) a zvyšok nech prevezme ďalšie volanie.
5. Nasmerujte naň plánovač.

Voľby plánovača:

• Naplánované workflowy v GitHub Actions. Zadarmo v rámci limitov použitia GitHubu. Podľa dokumentácie GitHubu zo septembra 2026 je najkratší interval raz za 5 minút, spustenia sa môžu oneskoriť v čase vysokého zaťaženia (najmä na začiatku každej hodiny), rozvrhy používajú štandardne UTC a naplánované workflowy vo verejnom repozitári sa vypnú po 60 dňoch bez aktivity v repozitári.
• Hostované cron služby. Existuje veľa služieb, ktorých jediná úloha je volať URL podľa rozvrhu. Pred tým, ako sa na jednu spoľahnete, skontrolujte spoľahlivosť, minimálny interval a upozorňovanie.
• Plánovač vášho cloudového poskytovateľa. Ak už používate veľkého cloudového poskytovateľa, má spravovaný plánovač, ktorý vie volať HTTPS endpoint.
• Hostovaná služba úloh alebo workflowov. Tieto kombinujú plánovanie, fronty a opakovania a volajú vaše endpointy pri každom kroku. Cenu a limity porovnajte na stránke každého dodávateľa.

Vzor 3: nechajte to na poskytovateľovi

Niekedy je najlepšou úlohou na pozadí žiadna:

• Platby. Stripe opakuje neúspešné platby predplatného a posiela webhooky; vy reagujete namiesto dotazovania. Pozrite si čo je webhook.
• E-mail. Poskytovatelia po odovzdaní správy radia doručovanie do fronty a opakujú ho.
• Hromadná práca s AI. OpenAI a Anthropic ponúkajú dávkové API pre nenaliehavé požiadavky, ktoré odošlete a neskôr vyzbierate.

Prompty pre váš AI nástroj

Pre frontu:

Pridaj frontu úloh na pozadí pomocou tabuľky jobs v našej databáze (typ, payload JSON, stav, attempts, run_after, last_error). Keď sa používateľ zaregistruje, vlož úlohu send_welcome_email v tej istej transakcii namiesto odosielania priamo. Pridaj funkciu processJobs(limit), ktorá preberá splatné úlohy cez SELECT ... FOR UPDATE SKIP LOCKED, spúšťa ich a pri zlyhaní opakuje po 1, 5 a 30 minútach a po 4 pokusoch ich označí ako failed.

Pre naplánovaný spúšťač:

Pridaj POST /api/cron/tick chránený bearer tokenom z tajomstva CRON_SECRET; odmietni každú požiadavku bez neho. Každé volanie spustí processJobs(100) a odošle pripomienky rezervácií, ktoré sú splatné v najbližších 24 hodinách a ešte neboli odoslané; odoslané pripomienky zaznamenaj, aby sa nič neodoslalo dvakrát. Vráť JSON súhrn toho, čo sa spustilo. Potom napíš workflow GitHub Actions, ktorý volá tento endpoint každých 15 minút a číta URL a token z tajomstiev repozitára.

Bežné chyby

• Spoliehanie sa na setInterval. Potichu sa zastaví, keď server zaspí alebo sa reštartuje, a zdvojí sa, keď bežia dve kópie.
• Nechránený cron endpoint. Ktokoľvek, kto ho nájde, môže spustiť vaše úlohy alebo zvýšiť váš účet za e-mail.
• Úlohy, ktoré nie sú idempotentné. Opakovania a duplicitné volania plánovača sa stanú. Navrhnite na to.
• Žiadna viditeľnosť zlyhaní. Úloha, ktorá týždeň zlyháva potichu, je horšia než tá, ktorá zlyhá nahlas. Zapisujte chyby a upozorňujte na opakované zlyhania.
• Dlhé behy v jednej požiadavke. Požiadavky vypršia na časový limit. Spracúvajte po dávkach.
• Plánovanie príliš často. Každé volanie na hostingu, ktorý škáluje na nulu, prebudí a spoplatní aplikáciu. Prispôsobte interval skutočnej potrebe.
• Časové pásma. „9:00“ znamená niečo iné pre váš plánovač (zvyčajne UTC) a pre vašich používateľov. Časy ukladajte v UTC a prevádzajte ich pre každého používateľa.
• Tajomstvá v súbore workflowu. Tokeny držte v úložisku tajomstiev plánovača. Pozrite si ako bezpečne uchovávať API kľúče.

Kontrolný zoznam

• Pomalá práca presunutá mimo požiadaviek používateľov
• Úlohy uložené trvanlivo, nie len v pamäti
• Opakovania s rastúcimi oneskoreniami a maximom
• Každá úloha sa dá bezpečne spustiť dvakrát
• Naplánovaný endpoint chránený tajným tokenom
• Každý beh spracuje ohraničenú dávku
• Zlyhané úlohy sú viditeľné, s upozorneniami
• Interval plánovania zvolený s ohľadom na náklady na hosting
• Časy uložené v UTC

Úlohy na pozadí v Mythex

Dokumentácia Mythex nepopisuje naplánované ani cron úlohy a publikované aplikácie aj ich databázy pri nečinnosti zaspia a prebudia sa pri ďalšej požiadavke (pozrite si Limity hostingu). Preto sa nespoliehajte na časovače vo vnútri aplikácie. Funguje prístup vyššie: požiadajte agenta o tabuľku úloh a endpoint chránený tokenom a potom na publikovanú URL nasmerujte externý plánovač. Token uložte ako tajomstvo projektu a pamätajte, že každé prebudenie minie kredity za čas, počas ktorého sú aplikácia a databáza hore, takže zvoľte rozumný interval. Ak vaša aplikácia na to potrebuje backend API, recept na REST API backend je východiskový bod a ako vytvoriť REST API vysvetľuje navrhovanie endpointov. Ak je jadrom vášho produktu trvalo bežiaci worker alebo bot, lepšie môže vyhovovať hosting určený na dlhodobo bežiace procesy.

Otázky