Jak spouštět úlohy na pozadí ve webové aplikaci: fronty, plánovače a cron

Abyste spouštěli úlohy na pozadí ve webové aplikaci, nejdřív rozdělte práci na dva druhy. Spouštěné úlohy (poslat uvítací e-mail, zpracovat nahraný soubor) lze uložit do fronty úloh, často tabulky v databázi, a zpracovat workerem s opakováním. Naplánované úlohy (noční report, připomínky každých 15 minut) potřebují něco, co se spouští podle času: cron funkci hostingu, nebo externí plánovač, který volá chráněný endpoint ve vaší aplikaci. Úlohy vždy navrhujte tak, aby bezpečně běžely dvakrát, zaznamenávejte selhání a nikdy se nespoléhejte na časovač uvnitř serveru, který může usnout nebo se restartovat.

Tento návod vysvětluje možnosti, kdy se která hodí a jak je nastavit s AI nástrojem pro tvorbu aplikací, včetně hostingů, které škálují na nulu.

Co je úloha na pozadí

Cokoli pomalého, nespolehlivého nebo nepotřebného pro okamžitou odpověď uživateli:

• Odesílání e-mailů, upozornění a účtenek
• Zmenšování obrázků, transkódování videa, generování PDF
• Volání pomalých API třetích stran, včetně AI modelů pro dlouhé úlohy
• Import nebo synchronizace dat z jiného systému
• Noční úklid, reporty a připomínky

Když se to dělá přímo v požadavku, stránky zpomalují a jsou křehké: pokud je poskytovatel e-mailů nedostupný, selže registrace uživatele. Přesunutí na pozadí znamená, že uživatel dostane okamžitou odpověď a úlohu lze zopakovat.

Možnosti

Neexistuje jedna správná odpověď. Malá aplikace často potřebuje jen databázovou frontu a externí plánovač.

Proč hostingy, které škálují na nulu, mění situaci

Mnoho moderních hostingů uspává vaši aplikaci, když ji nikdo nepoužívá, a probouzí ji při dalším požadavku. To šetří peníze, ale spící server nespouští žádný kód: časovače se nespouštějí a workery nedotazují. Na těchto hostinzích musí naplánovaná práce začít příchozím požadavkem a nejsnadnějším zdrojem takového požadavku je externí plánovač. Každé volání aplikaci (a často i databázi) probudí, takže volání každou minutu stojí víc než každých 15 minut. Vyberte nejpomalejší rozvrh, který splní potřebu.

Vzor 1: databázová fronta úloh

Pro spouštěné úlohy:

1. Vytvořte tabulku jobs: typ, payload (JSON), stav (pending, running, done, failed), pokusy, run_after, last_error, časová razítka.
2. Když se něco stane, vložte řádek úlohy ve stejné transakci jako změnu, která ji vyvolala, aby uspěly nebo selhaly společně.
3. Worker vezme splatné úlohy, označí je running, provede práci a označí je done.
4. Při selhání zvyšte attempts, nastavte run_after později (například za 1, 5, pak 30 minut) a uložte chybu. Po maximálním počtu ji označte jako failed a upozorněte někoho.

Pokud může běžet více workerů současně, úlohy je třeba převzít bezpečně. V Postgresu SELECT ... FOR UPDATE SKIP LOCKED umožní každému workeru převzít jiné řádky bez kolize.

Co worker spustí? Na serveru, který běží pořád, smyčku v samostatném procesu. Na hostingu, který škáluje na nulu, může naplánovaný endpoint z Vzoru 2 zpracovat dávku splatných úloh při každém volání.

Vzor 2: externí plánovač volající vaši aplikaci

Pro naplánované úlohy:

1. Přidejte endpoint, například POST /api/cron/send-reminders.
2. Chraňte ho: vyžadujte tajný token v hlavičce, uložený jako tajemství na obou stranách, a odmítněte cokoli jiného.
3. Udělejte ho idempotentním: spuštění dvakrát ve stejné minutě nesmí poslat dvě připomínky. Zaznamenávejte, co bylo odesláno.
4. Udržujte každé volání krátké: zpracujte dávku (řekněme 100 položek) a další volání vezme zbytek.
5. Nasměrujte na něj plánovač.

Volba plánovače:

• GitHub Actions naplánované workflow. Zdarma v rámci limitů využití GitHubu. Podle dokumentace GitHubu z září 2026 je nejkratší interval jednou za 5 minut, spuštění se mohou zpozdit v husté době (zvlášť na začátku každé hodiny), rozvrhy používají ve výchozím nastavení UTC a naplánovaná workflow ve veřejném repozitáři se vypnou po 60 dnech bez aktivity v repozitáři.
• Hostované cron služby. Existuje mnoho služeb, jejichž jediným úkolem je volat URL podle rozvrhu. Před tím, než na jednu spolehnete, ověřte spolehlivost, minimální interval a upozornění.
• Plánovač vašeho cloudového poskytovatele. Pokud už používáte velkého cloudového poskytovatele, bude mít spravovaný plánovač, který umí volat HTTPS endpoint.
• Hostovaná služba úloh nebo workflow. Ty kombinují plánování, fronty a opakování a volají vaše endpointy pro každý krok. Ceny a limity porovnejte na webu každého dodavatele.

Vzor 3: nechte to na poskytovateli

Někdy nejlepší úloha na pozadí žádná není:

• Platby. Stripe opakuje neúspěšné platby předplatného a posílá webhooky; vy reagujete, místo abyste dotazovali. Viz co je webhook.
• E-maily. Poskytovatelé řadí doručení do fronty a opakují ho, jakmile jim předáte zprávu.
• Hromadná práce s AI. OpenAI a Anthropic nabízejí dávková API pro nenaléhavé požadavky, které odešlete a později vyzvednete.

Prompty pro váš AI nástroj

Pro frontu:

Přidej frontu úloh na pozadí pomocí tabulky jobs v naší databázi (typ, payload JSON, stav, attempts, run_after, last_error). Když se uživatel zaregistruje, vlož úlohu send_welcome_email ve stejné transakci místo odeslání přímo. Přidej funkci processJobs(limit), která převezme splatné úlohy pomocí SELECT ... FOR UPDATE SKIP LOCKED, provede je a při selhání je opakuje po 1, 5 a 30 minutách; po 4 pokusech je označí jako failed.

Pro naplánované spuštění:

Přidej POST /api/cron/tick chráněný bearer tokenem z tajemství CRON_SECRET; odmítni každý požadavek bez něj. Každé volání spustí processJobs(100) a odešle připomínky rezervací splatné během následujících 24 hodin, které ještě nebyly odeslány, a odeslané připomínky zaznamená, aby se nic neodeslalo dvakrát. Vrať JSON souhrn toho, co proběhlo. Pak napiš workflow v GitHub Actions, které tento endpoint volá každých 15 minut a URL a token čte z tajemství repozitáře.

Časté chyby

• Spoléhání na setInterval. Tiše přestane, když server usne nebo se restartuje, a zdvojí se, když běží dvě kopie.
• Nechráněný cron endpoint. Kdokoli ho najde, může spustit vaše úlohy nebo vaši fakturu za e-maily.
• Úlohy, které nejsou idempotentní. Opakování a duplicitní volání plánovače se budou dít. Navrhujte na to.
• Žádná viditelnost selhání. Úloha, která tiše selhává týden, je horší než ta, která hlasitě selže. Zaznamenávejte chyby a upozorňujte na opakovaná selhání.
• Dlouhé běhy v jediném požadavku. Požadavky vyprší. Zpracovávejte po dávkách.
• Plánování příliš často. Každé volání na hostingu, který škáluje na nulu, probudí a zpoplatní aplikaci. Sladěte interval se skutečnou potřebou.
• Časová pásma. „9 ráno“ znamená jinou dobu pro váš plánovač (často UTC) a pro vaše uživatele. Ukládejte časy v UTC a převádějte je pro každého uživatele.
• Tajemství v souboru workflow. Tokeny držte v úložišti tajemství plánovače. Viz jak chránit API klíče.

Kontrolní seznam

• Pomalá práce přesunutá z požadavků uživatele
• Úlohy uložené trvale, ne jen v paměti
• Opakování s rostoucími prodlevami a maximem
• Každá úloha bezpečná pro dvojí spuštění
• Naplánovaný endpoint chráněný tajným tokenem
• Každé spuštění zpracuje omezenou dávku
• Selhané úlohy jsou vidět, s upozorněními
• Interval plánu zvolen s ohledem na náklady na hosting
• Časy uloženy v UTC

Úlohy na pozadí v Mythexu

Dokumentace Mythexu nepopisuje naplánované ani cron úlohy a publikované aplikace i jejich databáze při nečinnosti usínají a probouzejí se při dalším požadavku (viz Limity hostingu). Nespoléhejte se tedy na časovače uvnitř aplikace. Funguje přístup popsaný výše: požádejte agenta o tabulku úloh a endpoint chráněný tokenem a pak nasměrujte externí plánovač na vaši publikovanou URL. Token uložte jako tajemství projektu a pamatujte, že každé probuzení spotřebuje kredity za dobu, kdy jsou aplikace a databáze vzhůru, takže zvolte rozumný interval. Pokud vaše aplikace k tomu potřebuje API backend, je REST API backend výchozím bodem a jak vytvořit REST API popisuje návrh endpointů. Pokud jsou jádrem produktu trvale běžící workery nebo boti, může se lépe hodit hosting určený pro dlouhodobě běžící procesy.

Otázky