Si të ekzekutosh punë në sfond në një aplikacion web: radhë, planifikues dhe cron

Për të ekzekutuar punë në sfond në një aplikacion web, fillimisht ndaje punën në dy lloje. Punët e nisura (dërgo një email mirëseardhjeje, përpuno një ngarkim) mund të ruhen në një radhë pune, shpesh një tabelë në bazën e të dhënave, dhe të trajtohen nga një worker me riprovime. Punët e planifikuara (një raport nate, kujtesa çdo 15 minuta) kanë nevojë për diçka që zjen sipas një orari: një veçori cron e hostit, ose një planifikues të jashtëm që thërret një endpoint të mbrojtur në aplikacionin tënd. Bëj gjithmonë që punët të jenë të sigurta për t’u ekzekutuar dy herë, regjistro dështimet, dhe mos u mbështet kurrë në një kohëmatës brenda një serveri që mund të flejë ose të rinisë.

Ky udhëzues shpjegon opsionet, kur përshtaten secila, dhe si t’i konfigurosh me një ndërtues aplikacionesh me AI, edhe në hoste që zvogëlohen në zero.

Çfarë konsiderohet punë në sfond

Çdo gjë e ngadaltë, e pabesueshme ose që nuk nevojitet për përgjigjen e menjëhershme të përdoruesit:

• Dërgimi i emaileve, njoftimeve dhe faturave
• Ndryshimi i madhësisë së imazheve, kodimi i videove, gjenerimi i PDF-ve
• Thirrja e API-ve të ngadalta të palëve të treta, përfshirë modele AI për detyra të gjata
• Importimi ose sinkronizimi i të dhënave nga një sistem tjetër
• Pastrim natën, raporte dhe kujtesa

Bërja e kësaj brenda kërkesës i bën faqet të ngadalta dhe të brishta: nëse ofruesi i emailit është jashtë funksionit, regjistrimi i përdoruesit dështon. Zhvendosja në sfond do të thotë që përdoruesi merr një përgjigje të menjëhershme dhe puna mund të riprovohet.

Opsionet

Nuk ka një përgjigje të vetme të saktë. Një aplikacion i vogël zakonisht ka nevojë vetëm për një radhë në bazën e të dhënave plus një planifikues të jashtëm.

Pse hostet që zvogëlohen në zero e ndryshojnë pamjen

Shumë hoste moderne e vënë aplikacionin të flejë kur askush nuk e përdor dhe e zgjojnë te kërkesa e radhës. Kjo kursen para, por një server që flen nuk ekzekuton kod: kohëmatësit nuk ndezen dhe worker-at nuk kontrollojnë. Në këto hoste, puna e planifikuar duhet të nisë me një kërkesë hyrëse, dhe burimi më i lehtë për atë kërkesë është një planifikues i jashtëm. Çdo thirrje zgjon aplikacionin (dhe shpesh bazën e tij të të dhënave), kështu që thirrja çdo minutë kushton më shumë sesa çdo 15 minuta. Zgjidh orarin më të ngadalshëm që plotëson nevojën.

Model 1: një radhë pune në bazën e të dhënave

Për punët e nisura:

1. Krijo një tabelë jobs: lloji, payload (JSON), statusi (pending, running, done, failed), attempts, run_after, last_error, kohët.
2. Kur ndodh diçka, fut një rresht pune në të njëjtën transaksion me ndryshimin që e shkaktoi, që të shkojnë mirë ose të dështojnë së bashku.
3. Një worker i merr punët e gatshme, i shënon si running, bën punën dhe i shënon si done.
4. Kur dështon, rrit attempts, vendos run_after më vonë (për shembull 1, 5, pastaj 30 minuta) dhe ruaj gabimin. Pas një maksimumi, shëno si failed dhe njofto dikë.

Nëse më shumë se një worker mund të punojë njëkohësisht, punët duhet të merren në mënyrë të sigurt. Në Postgres, SELECT ... FOR UPDATE SKIP LOCKED lejon çdo worker të marrë rreshta të ndryshëm pa u përplasur.

Çfarë e ekzekuton worker-in? Në një server gjithmonë të ndezur, një lak në një proces të veçantë. Në një host që zvogëlohet në zero, endpoint-i i planifikuar te Modeli 2 mund të përpunojë një grup punësh të gatshme në çdo thirrje.

Model 2: një planifikues i jashtëm që thërret aplikacionin tënd

Për punët e planifikuara:

1. Shto një endpoint si POST /api/cron/send-reminders.
2. Mbroje: kërko një token sekret në një header, i ruajtur si sekret në të dy anët, dhe refuzo çdo gjë tjetër.
3. Bëje idempotent: ekzekutimi dy herë në të njëjtën minutë nuk duhet të dërgojë dy kujtesa. Regjistro çfarë u dërgua.
4. Mbaj çdo thirrje të shkurtër: përpuno një grup (të themi 100 elementë) dhe lëre thirrjen tjetër të marrë pjesën tjetër.
5. Drejto një planifikues drejt tij.

Zgjedhjet e planifikuesit:

• Workflow-et e planifikuara të GitHub Actions. Falas brenda kufijve të përdorimit të GitHub. Sipas dokumentacionit të GitHub, që nga shtatori 2026, intervali më i shkurtër është një herë çdo 5 minuta, ekzekutimet mund të vonohen në orë të ngarkuara (sidomos në fillim të çdo ore), orarët përdorin UTC si default, dhe workflow-et e planifikuara në një repository publik çaktivizohen pas 60 ditësh pa aktivitet në repository.
• Shërbime cron të hostuara. Ekzistojnë shumë shërbime, qëllimi i vetëm i të cilave është të thërrasin një URL sipas orarit. Kontrollo besueshmërinë, intervalin minimal dhe alarmet para se të mbështetesh në një të tillë.
• Planifikuesi i ofruesit tënd cloud. Nëse përdor tashmë një ofrues të madh cloud, ai ka një planifikues të menaxhuar që mund të thërresë një endpoint HTTPS.
• Një shërbim i hostuar punësh ose workflow-sh. Këto kombinojnë planifikimin, radhët dhe riprovimet, dhe thërrasin endpoint-et e tua për çdo hap. Krahaso çmimet dhe limitet te faqja e secilit shitës.

Model 3: lëre ofruesin ta bëjë

Ndonjëherë puna më e mirë në sfond nuk është asnjë:

• Pagesat. Stripe riprovon pagesat e abonimeve që dështojnë dhe dërgon webhook-e; ti reagon në vend që të pyesësh. Shih çfarë është një webhook.
• Email. Ofruesit vendosin në radhë dhe riprovojnë dërgimin pasi ti ua ke dorëzuar mesazhin.
• Punë masive me AI. OpenAI dhe Anthropic ofrojnë API-t batch për kërkesa jo urgjente që i dorëzon dhe i mbledh më vonë.

Prompte për ndërtuesin tënd me AI

Për një radhë:

Shto një radhë pune në sfond duke përdorur një tabelë jobs në bazën tonë të të dhënave (lloji, payload JSON, statusi, attempts, run_after, last_error). Kur një përdorues regjistrohet, fut një punë send_welcome_email në të njëjtën transaksion në vend që ta dërgosh brenda kërkesës. Shto një funksion processJobs(limit) që merr punët e gatshme me SELECT ... FOR UPDATE SKIP LOCKED, i ekzekuton dhe riprovon dështimet pas 1, 5 dhe 30 minutash, duke i shënuar si failed pas 4 përpjekjesh.

Për një nisje të planifikuar:

Shto POST /api/cron/tick të mbrojtur me një bearer token nga sekreti CRON_SECRET; refuzo çdo kërkesë pa të. Çdo thirrje ekzekuton processJobs(100) dhe dërgon kujtesat e rezervimeve që duhet të dalin brenda 24 orëve të ardhshme dhe që nuk janë dërguar ende, duke regjistruar kujtesat e dërguara që të mos dërgohet asgjë dy herë. Kthe një përmbledhje JSON të asaj që u ekzekutua. Pastaj shkruaj një workflow të GitHub Actions që e thërret këtë endpoint çdo 15 minuta, duke lexuar URL-në dhe token-in nga sekretet e repository-t.

Gabimet e zakonshme

• Mbështetja te setInterval. Ndalon pa zë kur serveri fle ose rinisët, dhe dyfishohet kur punojnë dy kopje.
• Një endpoint cron i pambrojtur. Këdo që e gjen mund të nisë punët e tua, ose faturën tënde të email-eve.
• Punë që nuk janë idempotente. Riprovimet dhe thirrjet e dyfishta të planifikuesit do të ndodhin. Projekto për to.
• Pa dukshmëri dështimesh. Një punë që dështon në heshtje për një javë është më keq sesa një që dështon me zë. Regjistro gabimet dhe njofto për dështime të përsëritura.
• Ekzekutime të gjata brenda një kërkese të vetme. Kërkesat skadojnë. Përpuno me grupe.
• Planifikim shumë i shpeshtë. Çdo thirrje në një host që zvogëlohet në zero zgjon dhe faturon aplikacionin. Përshtat intervalin me nevojën reale.
• Zonat kohore. “Ora 9” do të thotë gjëra të ndryshme për planifikuesin tënd (shpesh UTC) dhe për përdoruesit e tu. Ruaj kohët në UTC dhe konverto për çdo përdorues.
• Sekrete në skedarin e workflow-it. Mbaj token-et në depon e sekreteve të planifikuesit. Shih si t’i mbash të sigurta çelësat API.

Listë kontrolli

• Puna e ngadaltë u zhvendos jashtë kërkesave të përdoruesve
• Punët ruhen në mënyrë të qëndrueshme, jo vetëm në memorie
• Riprovime me vonesa në rritje dhe një maksimum
• Çdo punë e sigurt për t’u ekzekutuar dy herë
• Endpoint-i i planifikuar i mbrojtur me një token sekret
• Çdo ekzekutim përpunon një grup të kufizuar
• Punët e dështuara janë të dukshme, me alarme
• Intervali i planifikimit është zgjedhur duke pasur parasysh koston e hostimit
• Kohët ruhen në UTC

Punët në sfond në Mythex

Dokumentacioni i Mythex nuk përshkruan punë të planifikuara ose cron, dhe aplikacionet e publikuara dhe bazat e tyre të dhënave flenë kur janë inaktive dhe zgjohen te kërkesa e radhës (shih Kufizimet e hostimit). Pra mos u mbështet në kohëmatës brenda aplikacionit. Qasja që funksionon është ajo më sipër: kërko nga agjenti një tabelë punësh dhe një endpoint të mbrojtur me token, pastaj drejto një planifikues të jashtëm drejt URL-së së publikuar. Ruaje token-in si sekret projekti, dhe mbaj mend që çdo zgjim shpenzon kredite për kohën që aplikacioni dhe baza e të dhënave janë zgjuar, kështu që zgjidh një interval të arsyeshëm. Nëse aplikacioni yt ka nevojë për një backend API për këtë, recipe-i REST API backend është një pikënisje, dhe si të ndërtosh një REST API mbulon projektimin e endpoint-eve. Nëse punëtorët ose botët gjithmonë aktivë janë bërthama e produktit tënd, një host i ndërtuar për procese të vazhdueshme mund të përshtatet më mirë.

Pyetje