Jak uruchamiać zadania w tle w aplikacji webowej: kolejki, harmonogramy i cron

Aby uruchamiać zadania w tle w aplikacji webowej, najpierw podziel pracę na dwa rodzaje. Zadania wyzwalane (wyślij e-mail powitalny, przetwórz upload) można zapisać w kolejce zadań, często jako tabela w bazie danych, i obsłużyć przez workera z ponawianiem. Zadania zaplanowane (nocny raport, przypomnienia co 15 minut) potrzebują czegoś, co uruchamia się według harmonogramu: funkcji cron hosta albo zewnętrznego harmonogramu, który wywołuje chroniony endpoint w Twojej aplikacji. Zawsze projektuj zadania tak, by dało się je uruchomić dwa razy, zapisuj błędy i nigdy nie polegaj na timerze w serwerze, który może zasnąć lub się zrestartować.

Ten przewodnik wyjaśnia opcje, kiedy która pasuje i jak je ustawić z asystentem AI do budowania aplikacji, także na hostach, które skalują do zera.

Co liczy się jako zadanie w tle

Wszystko, co wolne, zawodne albo niepotrzebne do natychmiastowej odpowiedzi użytkownikowi:

• Wysyłka e-maili, powiadomień i paragonów
• Zmiana rozmiaru obrazów, transkodowanie wideo, generowanie PDF-ów
• Wywołania wolnych zewnętrznych API, w tym modeli AI przy długich zadaniach
• Import lub synchronizacja danych z innego systemu
• Nocne czyszczenie, raporty i przypomnienia

Robienie tego w ramach żądania sprawia, że strony są wolne i kruche: jeśli dostawca e-maili nie działa, rejestracja użytkownika się nie udaje. Przeniesienie tego w tło oznacza, że użytkownik dostaje natychmiastową odpowiedź, a zadanie można ponowić.

Opcje

Nie ma jednej właściwej odpowiedzi. Mała aplikacja często potrzebuje tylko kolejki w bazie danych i zewnętrznego harmonogramu.

Dlaczego hosty skalujące do zera zmieniają obraz

Wiele nowoczesnych hostów usypia aplikację, gdy nikt z niej nie korzysta, i budzi ją przy następnym żądaniu. To oszczędza pieniądze, ale uśpiony serwer nie wykonuje kodu: timery nie odpalają się, a workery nie odpytują. Na takich hostach zaplanowana praca musi zacząć się od przychodzącego żądania, a najprostszym źródłem takiego żądania jest zewnętrzny harmonogram. Każde wywołanie budzi aplikację (i często jej bazę danych), więc wywołanie co minutę kosztuje więcej niż co 15 minut. Wybierz najrzadszy harmonogram, który spełnia potrzebę.

Wzorzec 1: kolejka zadań w bazie danych

Dla zadań wyzwalanych:

1. Utwórz tabelę jobs: typ, ładunek (JSON), status (pending, running, done, failed), liczba prób, run_after, last_error, znaczniki czasu.
2. Gdy coś się wydarzy, wstaw wiersz zadania w tej samej transakcji co zmiana, która je wywołała, żeby oba powiodły się lub zawiodły razem.
3. Worker pobiera zadania gotowe do wykonania, oznacza je jako running, wykonuje pracę i oznacza jako done.
4. Przy błędzie zwiększ attempts, ustaw run_after na późniejszy czas (na przykład 1, 5, potem 30 minut) i zapisz błąd. Po maksymalnej liczbie prób oznacz zadanie jako failed i powiadom kogoś.

Jeśli może działać więcej niż jeden worker naraz, zadania trzeba pobierać bezpiecznie. W Postgresie SELECT ... FOR UPDATE SKIP LOCKED pozwala każdemu workerowi pobrać inne wiersze bez kolizji.

Co uruchamia workera? Na serwerze, który zawsze działa, pętla w osobnym procesie. Na hoście skalującym do zera zaplanowany endpoint z Wzorca 2 może przetworzyć partię gotowych zadań przy każdym wywołaniu.

Wzorzec 2: zewnętrzny harmonogram wywołujący Twoją aplikację

Dla zadań zaplanowanych:

1. Dodaj endpoint, na przykład POST /api/cron/send-reminders.
2. Zabezpiecz go: wymagaj tajnego tokenu w nagłówku, przechowywanego jako sekret po obu stronach, i odrzucaj wszystko inne.
3. Uczyń go idempotentnym: uruchomienie dwa razy w tej samej minucie nie może wysłać dwóch przypomnień. Zapisuj, co zostało wysłane.
4. Trzymaj każde wywołanie krótkim: przetwarzaj partię (powiedzmy 100 elementów), a następne wywołanie podejmie resztę.
5. Skieruj harmonogram na ten endpoint.

Wybór harmonogramu:

• Zaplanowane workflow w GitHub Actions. Bezpłatne w ramach limitów użycia GitHub. Według dokumentacji GitHub z września 2026 najkrótszy interwał to raz na 5 minut, uruchomienia mogą być opóźnione w godzinach szczytu (zwłaszcza na początku każdej godziny), harmonogramy używają domyślnie UTC, a zaplanowane workflow w repozytorium publicznym są wyłączane po 60 dniach bez aktywności w repozytorium.
• Hostowane usługi cron. Istnieje wiele usług, których jedynym zadaniem jest wywoływanie adresu URL według harmonogramu. Przed uzależnieniem się sprawdź niezawodność, minimalny interwał i alerty.
• Harmonogram Twojego dostawcy chmury. Jeśli już korzystasz z dużego dostawcy chmury, będzie mieć zarządzany harmonogram, który może wywoływać endpoint HTTPS.
• Hostowana usługa zadań lub workflow. Łączą harmonogramy, kolejki i ponowienia i wywołują Twoje endpointy dla każdego kroku. Porównaj ceny i limity na stronach poszczególnych dostawców.

Wzorzec 3: niech zrobi to dostawca

Czasem najlepsze zadanie w tle to brak zadania:

• Płatności. Stripe ponawia nieudane płatności subskrypcji i wysyła webhooki; Ty reagujesz zamiast odpytywać. Zobacz czym jest webhook.
• E-mail. Dostawcy kolejkują i ponawiają dostarczanie, gdy przekażesz wiadomość.
• Masowa praca AI. OpenAI i Anthropic oferują API wsadowe dla niepilnych żądań, które wysyłasz i odbierasz później.

Prompty dla Twojego asystenta AI

Dla kolejki:

Dodaj kolejkę zadań w tle, używając tabeli jobs w naszej bazie danych (typ, payload JSON, status, attempts, run_after, last_error). Gdy użytkownik się rejestruje, wstaw zadanie send_welcome_email w tej samej transakcji zamiast wysyłać inline. Dodaj funkcję processJobs(limit), która pobiera gotowe zadania przez SELECT ... FOR UPDATE SKIP LOCKED, wykonuje je i ponawia błędy po 1, 5 i 30 minutach, oznaczając je jako failed po 4 próbach.

Dla wyzwalacza zaplanowanego:

Dodaj POST /api/cron/tick chroniony tokenem bearer z sekretu CRON_SECRET; odrzucaj każde żądanie bez niego. Każde wywołanie uruchamia processJobs(100) i wysyła przypomnienia o rezerwacjach, które mają nadejść w ciągu 24 godzin i jeszcze nie zostały wysłane, zapisując wysłane przypomnienia, żeby nic nie poszło dwa razy. Zwróć podsumowanie w JSON, co zostało uruchomione. Potem napisz workflow GitHub Actions, który wywołuje ten endpoint co 15 minut, czytając adres URL i token z sekretów repozytorium.

Częste błędy

• Poleganie na setInterval. Po cichu przestaje działać, gdy serwer śpi lub się restartuje, a przy dwóch kopiach dubluje się.
• Niezabezpieczony endpoint cron. Każdy, kto go znajdzie, może uruchomić Twoje zadania albo wygenerować Twój rachunek za e-maile.
• Zadania nieidempotentne. Ponowienia i zduplikowane wywołania harmonogramu będą się zdarzać. Projektuj z myślą o nich.
• Brak widoczności błędów. Zadanie, które po cichu zawodzi przez tydzień, jest gorsze niż takie, które głośno się zgłasza. Loguj błędy i alarmuj przy powtarzających się niepowodzeniach.
• Długie przebiegi w jednym żądaniu. Żądania się przekraczają czasowo. Przetwarzaj partiami.
• Zbyt częste harmonogramy. Każde wywołanie na hoście skalującym do zera budzi i obciąża aplikację. Dopasuj interwał do realnej potrzeby.
• Strefy czasowe. „9 rano” znaczy co innego dla harmonogramu (często UTC) i dla użytkowników. Przechowuj czas w UTC i konwertuj dla każdego użytkownika.
• Sekrety w pliku workflow. Trzymaj tokeny w magazynie sekretów harmonogramu. Zobacz jak chronić klucze API.

Lista kontrolna

• Powolna praca przeniesiona poza żądania użytkowników
• Zadania przechowywane trwale, a nie tylko w pamięci
• Ponowienia z rosnącymi opóźnieniami i maksimum prób
• Każde zadanie bezpieczne do uruchomienia dwa razy
• Zaplanowany endpoint chroniony tajnym tokenem
• Każde uruchomienie przetwarza ograniczoną partię
• Nieudane zadania widoczne, z alertami
• Interwał harmonogramu dobrany z uwzględnieniem kosztów hostingu
• Czasy przechowywane w UTC

Zadania w tle w Mythex

Dokumentacja Mythex nie opisuje zaplanowanych ani cronowych zadań, a opublikowane aplikacje i ich bazy danych zasypiają, gdy są bezczynne, i budzą się przy następnym żądaniu (zobacz Limity hostingu). Dlatego nie polegaj na timerach w swojej aplikacji. Działa podejście opisane wyżej: poproś agenta o tabelę jobs i endpoint chroniony tokenem, a potem skieruj zewnętrzny harmonogram na swój opublikowany adres URL. Przechowuj token jako sekret projektu i pamiętaj, że każde wybudzenie zużywa kredyty za czas, w którym aplikacja i baza były aktywne, więc wybierz rozsądny interwał. Jeśli Twoja aplikacja potrzebuje do tego backendu API, przepis na REST API backend to dobry punkt startowy, a jak zbudować REST API opisuje projektowanie endpointów. Jeśli sednem Twojego produktu są stale działające workery lub boty, lepiej może pasować host stworzony do trwałych procesów.

Pytania