Slik kjører du bakgrunnsjobber i en webapp: køer, planleggere og cron

For å kjøre bakgrunnsjobber i en webapp må du først dele arbeidet i to typer. Utløste jobber (send en velkomst-e-post, behandle en opplasting) kan lagres i en jobbkø, ofte en tabell i databasen din, og håndteres av en arbeider med nye forsøk. Planlagte jobber (en nattlig rapport, påminnelser hvert 15. minutt) trenger noe som starter etter en tidsplan: hostens cron-funksjon, eller en ekstern planlegger som kaller et beskyttet endepunkt i appen din. Gjør alltid jobbene trygge å kjøre to ganger, logg feil, og stol aldri på en timer inne i en server som kan sove eller starte på nytt.

Denne guiden forklarer alternativene, når hvert passer, og hvordan du setter dem opp med en AI-appbygger, også på hoster som skalerer til null.

Hva som regnes som en bakgrunnsjobb

Alt som er tregt, upålitelig eller ikke trengs for brukerens umiddelbare svar:

• Sending av e-poster, varsler og kvitteringer
• Skalering av bilder, transkoding av video, generering av PDF-er
• Kall til trege tredjeparts-API-er, inkludert AI-modeller for lange oppgaver
• Import eller synkronisering av data fra et annet system
• Nattlig opprydding, rapporter og påminnelser

Gjør du dette inne i forespørselen, blir sider trege og skjøre: hvis e-postleverandøren er nede, feiler brukerens registrering. Flytter du det til bakgrunnen, får brukeren et umiddelbart svar, og jobben kan prøves på nytt.

Alternativene

Det finnes ikke ett riktig svar. En liten app trenger ofte bare en databasekø pluss en ekstern planlegger.

Hvorfor hoster som skalerer til null endrer bildet

Mange moderne hoster legger appen din til å sove når ingen bruker den, og vekker den ved neste forespørsel. Det sparer penger, men en sovende server kjører ingen kode: timere avfyres ikke og arbeidere spør ikke etter jobber. På disse hostene må planlagt arbeid starte med en innkommende forespørsel, og den enkleste kilden til den forespørselen er en ekstern planlegger. Hvert kall vekker appen (og ofte databasen), så å kalle hvert minutt koster mer enn hvert 15. minutt. Velg den tregeste tidsplanen som dekker behovet.

Mønster 1: en databasejobbkø

For utløste jobber:

1. Opprett en tabell jobs: type, nyttelast (JSON), status (pending, running, done, failed), attempts, run_after, last_error, tidsstempler.
2. Når noe skjer, sett inn en jobbrad i samme transaksjon som endringen som utløste den, slik at de lykkes eller feiler sammen.
3. En arbeider plukker opp forfalne jobber, markerer dem running, utfører arbeidet og markerer dem done.
4. Ved feil øker du attempts, setter run_after senere (for eksempel 1, 5, så 30 minutter) og lagrer feilen. Etter et maksimum markerer du den failed og varsler noen.

Hvis flere arbeidere kan kjøre samtidig, må jobbene tas på en trygg måte. På Postgres lar SELECT ... FOR UPDATE SKIP LOCKED hver arbeider ta forskjellige rader uten å kollidere.

Hva kjører arbeideren? På en server som alltid er på, en løkke i en egen prosess. På en vert som skalerer til null kan det planlagte endepunktet i Mønster 2 behandle en batch med forfalne jobber ved hvert kall.

Mønster 2: en ekstern planlegger som kaller appen din

For planlagte jobber:

1. Legg til et endepunkt som POST /api/cron/send-reminders.
2. Beskytt det: krev en hemmelig token i en header, lagret som hemmelighet på begge sider, og avvis alt annet.
3. Gjør det idempotent: å kjøre det to ganger i samme minutt må ikke sende to påminnelser. Registrer hva som er sendt.
4. Hold hvert kall kort: behandle en batch (si 100 elementer) og la neste kall ta resten.
5. Pek en planlegger mot det.

Valg av planlegger:

• GitHub Actions-planlagte arbeidsflyter. Gratis innenfor GitHubs bruksgrenser. Fra september 2026 sier GitHubs dokumentasjon at kortest intervall er én gang hvert 5. minutt, kjøringer kan forsinkes i travle perioder (særlig ved starten av hver time), planer bruker UTC som standard, og planlagte arbeidsflyter i et offentlig repository deaktiveres etter 60 dager uten aktivitet i repositoryet.
• Tjenester for cron i skyen. Det finnes mange tjenester som bare skal kalle en URL etter tidsplan. Sjekk pålitelighet, minimumsintervall og varsling før du stoler på en.
• Planleggeren til skyleverandøren din. Hvis du allerede bruker en stor skyleverandør, har den en administrert planlegger som kan kalle et HTTPS-endepunkt.
• En vert-tjeneste for jobber eller arbeidsflyt. Disse kombinerer planlegging, køer og nye forsøk, og kaller endepunktene dine for hvert steg. Sammenlign priser og grenser på hver leverandørs nettsted.

Mønster 3: la leverandøren gjøre jobben

Noen ganger er den beste bakgrunnsjobben ingen jobb i det hele tatt:

• Betalinger. Stripe prøver mislykkede abonnementsbetalinger på nytt og sender webhooks; du reagerer i stedet for å spørre. Se hva en webhook er.
• E-post. Leverandører legger meldinger i kø og prøver levering på nytt når du har overlevert meldingen.
• Masse-AI-arbeid. OpenAI og Anthropic tilbyr batch-API-er for ikke-haste forespørsler som du sender inn og henter senere.

Ledetekster du kan gi AI-appbyggeren din

For en kø:

Legg til en bakgrunnsjobbkø ved hjelp av en jobs-tabell i databasen vår (type, nyttelast JSON, status, attempts, run_after, last_error). Når en bruker registrerer seg, sett inn en send_welcome_email-jobb i samme transaksjon i stedet for å sende inline. Legg til en funksjon processJobs(limit) som tar forfalne jobber med SELECT ... FOR UPDATE SKIP LOCKED, kjører dem, og prøver feilede jobber på nytt etter 1, 5 og 30 minutter, og markerer dem failed etter 4 forsøk.

For en planlagt utløser:

Legg til POST /api/cron/tick beskyttet av en bearer-token fra hemmeligheten CRON_SECRET; avvis enhver forespørsel uten den. Hvert kall kjører processJobs(100) og sender bookingpåminnelser som forfaller i løpet av de neste 24 timene og ikke er sendt ennå, og registrerer sendte påminnelser slik at ingenting sendes to ganger. Returner et JSON-sammendrag av det som kjørte. Skriv deretter en GitHub Actions-arbeidsflyt som kaller dette endepunktet hvert 15. minutt, og leser URL-en og tokenen fra repository-hemmelighetene.

Vanlige feil

• Å stole på setInterval. Den stopper stille når serveren sover eller starter på nytt, og doblers når to kopier kjører.
• Et ubeskyttet cron-endepunkt. Hvem som helst som finner det kan utløse jobbene dine, eller regningen din for e-post.
• Jobber som ikke er idempotente. Nye forsøk og doble planleggerkall vil skje. Design for det.
• Ingen synlighet på feil. En jobb som feiler stille i en uke er verre enn en som feiler høylytt. Logg feil og varsle ved gjentatte feil.
• Lange kjøringer i ett enkelt kall. Forespørsler får tidsavbrudd. Behandle i batcher.
• Planlegging for ofte. Hvert kall på en vert som skalerer til null vekker og fakturerer appen. Tilpass intervallet til det reelle behovet.
• Tidssoner. «9 om morgenen» betyr forskjellige ting for planleggeren din (ofte UTC) og for brukerne dine. Lagre tider i UTC og konverter per bruker.
• Hemmeligheter i arbeidsflytfilen. Hold tokens i planleggerens hemmelighetslager. Se slik holder du API-nøkler trygge.

Sjekkliste

• Tregt arbeid er flyttet ut av brukerforespørsler
• Jobber lagres holdbart, ikke bare i minnet
• Nye forsøk med økende forsinkelser og et maksimum
• Hver jobb kan kjøres to ganger trygt
• Planlagt endepunkt er beskyttet av en hemmelig token
• Hver kjøring behandler en avgrenset batch
• Feilede jobber er synlige, med varsler
• Planleggingsintervall valgt med hostingkostnaden i tankene
• Tider lagres i UTC

Bakgrunnsjobber i Mythex

Mythex sin dokumentasjon beskriver ikke planlagte eller cron-jobber, og publiserte apper og databasene deres sover når de er inaktive og våkner ved neste forespørsel (se Hostingbegrensninger). Stol derfor ikke på timere inne i appen din. Tilnærmingen som fungerer er den over: be agenten om en jobs-tabell og et endepunkt beskyttet av en token, og pek deretter en ekstern planlegger mot den publiserte URL-en din. Lagre tokenen som en prosjekthemmelighet, og husk at hver oppvåkning bruker kreditter for tiden appen og databasen er våkne, så velg et fornuftig intervall. Hvis appen din trenger et API-backend til dette, er REST API-backend-oppskriften et utgangspunkt, og slik bygger du et REST API dekker design av endepunktene. Hvis alltid-på-arbeidere eller roboter er kjernen i produktet ditt, passer en vert bygget for vedvarende prosesser kanskje bedre.

Spørsmål