Com executar tasques en segon pla en una app web: cues, planificadors i cron

Per executar tasques en segon pla en una app web, primer separa la feina en dos tipus. Les tasques disparades (enviar un correu de benvinguda, processar una pujada) es poden desar en una cua de tasques, sovint una taula de la teva base de dades, i les gestiona un worker amb reintents. Les tasques programades (un informe nocturn, recordatoris cada 15 minuts) necessiten alguna cosa que s'activi segons un calendari: la funció de cron de l'allotjament o un planificador extern que cridi un endpoint protegit de la teva app. Fes sempre que les tasques es puguin executar dues vegades sense problemes, registra els errors i no confiïs mai en un temporitzador dins d'un servidor que pot adormir-se o reiniciar-se.

Aquesta guia explica les opcions, quan encaixa cadascuna i com configurar-les amb un constructor d'apps amb IA, incloent-hi els allotjaments que escalen a zero.

Què compta com a tasca en segon pla

Qualsevol cosa lenta, poc fiable o que no és necessària per a la resposta immediata de l'usuari:

• Enviar correus, notificacions i rebuts
• Redimensionar imatges, transcodificar vídeo, generar PDFs
• Cridar APIs lentes de tercers, incloent-hi models d'IA per a tasques llargues
• Importar o sincronitzar dades d'un altre sistema
• Neteja nocturna, informes i recordatoris

Fer-ho dins de la petició fa que les pàgines siguin lentes i fràgils: si el proveïdor de correu cau, el registre de l'usuari falla. Passar-ho a segon pla vol dir que l'usuari obté una resposta instantània i la tasca es pot tornar a intentar.

Les opcions

No hi ha una única resposta correcta. Una app petita sovint només necessita una cua en base de dades i un planificador extern.

Per què els allotjaments que escalen a zero canvien el panorama

Molts allotjaments moderns posen la teva app a dormir quan ningú no l'usa i la desperten amb la següent petició. Això estalvia diners, però un servidor adormit no executa codi: els temporitzadors no s'activen i els workers no sondegen. En aquests allotjaments, la feina programada ha de començar amb una petició entrant, i la font més fàcil d'aquesta petició és un planificador extern. Cada crida desperta l'app (i sovint la base de dades), així que cridar cada minut costa més que cada 15 minuts. Tria el calendari més espaiat que compleixi la necessitat.

Patró 1: una cua de tasques en base de dades

Per a tasques disparades:

1. Crea una taula jobs: tipus, càrrega útil (JSON), estat (pending, running, done, failed), intents, run_after, last_error, marques de temps.
2. Quan passa alguna cosa, insereix una fila de tasca dins de la mateixa transacció que el canvi que la va causar, perquè tots dos reeixeixin o fallin junts.
3. Un worker recull les tasques pendents, les marca com running, fa la feina i les marca com done.
4. Si falla, incrementa attempts, posa run_after més tard (per exemple 1, 5 i després 30 minuts) i desa l'error. Després d'un màxim, marca-la com failed i avisa algú.

Si més d'un worker pot executar-se alhora, les tasques s'han de reclamar de manera segura. A Postgres, SELECT ... FOR UPDATE SKIP LOCKED permet que cada worker reclami files diferents sense col·lisionar.

Qui executa el worker? En un servidor sempre encès, un bucle en un procés separat. En un allotjament que escala a zero, l'endpoint programat del Patró 2 pot processar un lot de tasques pendents a cada crida.

Patró 2: un planificador extern que crida la teva app

Per a tasques programades:

1. Afegeix un endpoint com POST /api/cron/send-reminders.
2. Protegeix-lo: exigeix un token secret en una capçalera, guardat com a secret a tots dos costats, i rebutja qualsevol altra cosa.
3. Fes-lo idempotent: executar-lo dues vegades en el mateix minut no ha d'enviar dos recordatoris. Registra què s'ha enviat.
4. Mantén cada crida curta: processa un lot (per exemple 100 elements) i deixa que la següent crida agafi la resta.
5. Apunta un planificador cap a ell.

Opcions de planificador:

• Workflows programats de GitHub Actions. Gratuïts dins dels límits d'ús de GitHub. Segons la documentació de GitHub a setembre de 2026, l'interval més curt és una vegada cada 5 minuts, les execucions es poden retardar en moments de molta càrrega (sobretot a l'inici de cada hora), els calendaris usen UTC per defecte, i els workflows programats en un repositori públic es desactiven després de 60 dies sense activitat al repositori.
• Serveis de cron allotjats. Hi ha molts serveis que només fan una cosa: cridar una URL segons un calendari. Comprova la fiabilitat, l'interval mínim i les alertes abans de dependre'n.
• El planificador del teu proveïdor de núvol. Si ja uses un proveïdor de núvol gran, tindrà un planificador gestionat que pot cridar un endpoint HTTPS.
• Un servei allotjat de tasques o workflows. Combinen programació, cues i reintents, i criden els teus endpoints per a cada pas. Compara preus i límits a la web de cada proveïdor.

Patró 3: deixa que ho faci el proveïdor

De vegades la millor tasca en segon pla és cap:

• Pagaments. Stripe reintenta els pagaments fallits de les subscripcions i envia webhooks; tu reacciones en lloc de sondejar. Consulta què és un webhook.
• Correu. Els proveïdors encuen i reintenten el lliurament un cop els has passat el missatge.
• Feina massiva amb IA. OpenAI i Anthropic ofereixen APIs de lots per a peticions no urgents que envies i recull-los més tard.

Indicacions per al teu constructor d'apps amb IA

Per a una cua:

Afegeix una cua de tasques en segon pla fent servir una taula jobs a la nostra base de dades (tipus, payload JSON, estat, attempts, run_after, last_error). Quan un usuari es registra, insereix una tasca send_welcome_email dins de la mateixa transacció en lloc d'enviar el correu en línia. Afegeix una funció processJobs(limit) que reclami les tasques pendents amb SELECT ... FOR UPDATE SKIP LOCKED, les executi i torni a intentar els errors després de 1, 5 i 30 minuts, marcant-les com a failed després de 4 intents.

Per a un disparador programat:

Afegeix POST /api/cron/tick protegit per un bearer token del secret CRON_SECRET; rebutja qualsevol petició sense ell. Cada crida executa processJobs(100) i envia els recordatoris de reserva que toquen en les següents 24 hores i que encara no s'han enviat, registrant els recordatoris enviats perquè no se n'enviï cap dues vegades. Retorna un resum JSON del que s'ha executat. Després escriu un workflow de GitHub Actions que cridi aquest endpoint cada 15 minuts, llegint la URL i el token dels secrets del repositori.

Errors habituals

• Confiar en setInterval. Deixa de funcionar en silenci quan el servidor s'adorm o es reinicia, i es duplica quan hi ha dues còpies en marxa.
• Un endpoint de cron sense protecció. Qualsevol que el trobi pot disparar les teves tasques, o la teva factura de correu.
• Tasques no idempotents. Els reintents i les crides duplicades del planificador passaran. Dissenya-ho tenint-ho en compte.
• Cap visibilitat dels fallades. Una tasca que falla en silenci durant una setmana és pitjor que una que falla ben alt. Registra els errors i avisa quan es repeteixen.
• Execucions llargues en una sola petició. Les peticions caduquen. Processa per lots.
• Programar massa sovint. Cada crida en un allotjament que escala a zero desperta i factura l'app. Ajusta l'interval a la necessitat real.
• Fusos horaris. «Les 9» vol dir coses diferents per al teu planificador (sovint UTC) i per als teus usuaris. Desa les hores en UTC i converteix-les per usuari.
• Secrets al fitxer de workflow. Guarda els tokens al magatzem de secrets del planificador. Consulta com mantenir segures les claus d'API.

Llista de comprovació

• La feina lenta s'ha tret de les peticions dels usuaris
• Les tasques es desen de manera durable, no només a la memòria
• Reintents amb retards creixents i un màxim
• Cada tasca és segura per executar-se dues vegades
• L'endpoint programat està protegit amb un token secret
• Cada execució processa un lot acotat
• Les tasques fallides són visibles, amb alertes
• L'interval de programació s'ha triat tenint en compte el cost d'allotjament
• Les hores es desen en UTC

Tasques en segon pla a Mythex

La documentació de Mythex no descriu les tasques programades ni cron, i les apps publicades i les seves bases de dades s'adormen quan estan inactives i es desperten amb la següent petició (consulta Limitacions d'allotjament). Així que no confiïs en temporitzadors dins de la teva app. L'enfocament que funciona és el de dalt: demana a l'agent una taula de tasques i un endpoint protegit per token, i després apunta un planificador extern a la URL de la teva app publicada. Desa el token com a secret del projecte, i recorda que cada desvetllament gasta crèdits durant el temps que l'app i la base de dades estan despertes, així que tria un interval sensat. Si la teva app necessita un backend d'API per a això, la recepta backend d'API REST és un bon punt de partida, i com construir una API REST explica com dissenyar els endpoints. Si el teu producte gira al voltant de workers o bots sempre actius, potser t'encaixa més un allotjament pensat per a processos persistents.

Preguntes