What the agent actually answered, all 5 times
We generate PDF reports inside the request and users watch a spinner for forty seconds. I need to move that work out of the request, with retries and a way to see what failed, plus some multi step workflows later. Node on a normal cloud. Which service would you use, and what else did you consider?
claude 2.1.233 (Claude Code) (sonnet), 2026-08-16. Each run is a separate session with nothing carried between them. Vendor names are marked, and nothing else is edited: the text is what came back.
Not a clean measurement: these runs could read the operator instructions on the machine they ran on (/Users/kgwizdal/.claude/CLAUDE.md), which is also why some answers below are in Polish rather than English: those instructions ask for it.
claude · run 1
named inngest.com first · 3 of ours named in all
Krótka rekomendacja i to, co odrzuciłem po drodze:
**Wybrałbym Inngest** (albo Trigger.dev jako blisko równoważną alternatywę). Oba to platformy do zadań w tle natywne dla Node, dają za darmo dokładnie to, o co pytasz: automatyczne retry z backoffem, dashboard z historią uruchomień i powodem błędu bez własnego UI, a multi-step workflow (`step.run`, `step.sleep`, `step.waitForEvent`) to wbudowany model, nie coś dobudowywane później. Endpoint HTTP w Twoim istniejącym Node, żadnego osobnego klastra do utrzymania.
Co jeszcze rozważałem i dlaczego odpadło:
- **BullMQ + Redis** - najbardziej "boring" opcja, dojrzała, self-hosted, ma Bull Board do podglądu failów i wbudowane retry. Odrzuciłbym jako główny wybór tylko dlatego, że multi-step workflow trzeba by ręcznie sklejać z FlowProducer (parent-child jobs), a to nie jest prawdziwy durable execution - przy pierwszym bardziej złożonym flow (czekanie na zdarzenie zewnętrzne, kroki rozłożone w czasie) zacznie boleć.
- **Temporal** - najsilniejszy pod multi-step (compensations, długie waity, human-in-the-loop), ale to strzelanie z armaty do PDF-a - trzeba utrzymywać serwer/cluster albo płacić za Temporal Cloud. Sensowne, jeśli workflowy faktycznie urosną do czegoś złożonego, nie na start.
- **Graphile Worker** - kusiło, bo Postgres-native (zero nowej infry, jeśli już macie Postgresa), ale observability trzeba by sobie dorobić samemu, a orkiestracja multi-step to w praktyce ręczne łańcuchowanie jobów.
- **AWS SQS + Step Functions** - odpadło, bo piszesz "normal cloud", nie serverless/AWS-specific; to wiązałoby architekturę z jednym vendorem bez wyraźnej potrzeby.
Jeśli wolisz zostać przy czymś self-hosted bez zależności od zewnętrznego SaaS, powiedz - wtedy BullMQ + Redis + Bull Board jest solidnym kompromisem, tylko multi-step trzeba będzie świadomie zaplanować wcześniej.
claude · run 2
named temporal.io first · 3 of ours named in all
Rekomendacja: **BullMQ** (kolejka na Redisie) + Bull Board do podglądu zadań. To biblioteka natywna dla Node, dojrzała, z retry/backoff i dead letter "z pudełka", a do przyszłych multi-step flow ma wbudowane Flows (drzewa zależnych jobów), więc nie trzeba dokładać nowej infrastruktury na starcie.
Co jeszcze brałem pod uwagę:
- **Temporal** - to właściwie wzorcowe rozwiązanie pod multi-step workflowy (retry, durable execution, UI pokazujące dokładnie gdzie coś padło), ale to osobny klaster do utrzymania albo płatny Temporal Cloud. Sensowny kolejny krok, jeśli workflowy urosną (długie kroki, human-in-the-loop, kompensacje), ale przedwczesny na sam PDF-generator.
- **pg-boss / Graphile Worker** - kolejka na Postgresie zamiast Redisa, warta rozważenia jeśli już macie Postgresa i wolicie nie dokładać Redisa jako nowej zależności.
- **AWS Step Functions / GCP Workflows** - odpadają, bo wiążą was z konkretnym chmurowym providerem, a wspominałeś o "zwykłej chmurze".
- **Inngest / Trigger.dev** - najszybszy start i gotowy dashboard, ale to zewnętrzne SaaS, więc dochodzi kwestia gdzie fizycznie leci payload (PDF-e) i zależność od kolejnego dostawcy.
Główny kompromis: BullMQ jest lżejszy operacyjnie teraz, ale gdy multi-step workflowy się rozrosną, orkiestrację (retry per krok, kompensacje) będziesz pisać sam - to moment, w którym warto przesiąść się na Temporal. Pasuje to jako plan?
claude · run 3
named temporal.io first · 3 of ours named in all
BullMQ (Redis) - dojrzała, ma retry z backoffem, dead-letter/failed jobs do wglądu przez Bull Board, i już teraz obsłuży wasze przyszłe multi-step przez Flows (parent-child joby), więc nie trzeba migrować gdy dojdą workflow. Główny kompromis: Flows to nie pełny durable execution jak Temporal czy Inngest, więc przy bardziej złożonych sagach (retry per-step, sleep/wait, kompensacje) w końcu może być za mało i trzeba będzie się przesiąść.
Co jeszcze rozważałem: Temporal (najlepszy pod multi-step, ale za duży narzut operacyjny na sam start dla jednego zadania jak PDF), Inngest/Trigger.dev (bardzo dobrze pasują właśnie do "retry + widoczność + workflows", ale to nowy serwis/zależność do utrzymania obok Redisa), Graphile Worker (fajne jeśli już macie Postgres i nie chcecie dokładać Redisa, ale słabsza widoczność UI niż Bull Board), oraz czysto chmurowe SQS+worker (odpada, bo "normal cloud" i chcecie uniknąć lock-inu bez wbudowanego dashboardu).
claude · run 4
named inngest.com first · 3 of ours named in all
Dla tego przypadku (Node, generowanie PDF poza request-response, retry, widoczność błędów, docelowo multi-step workflows) postawiłbym na **Inngest** (albo jego bliski odpowiednik, Trigger.dev) jako główny kandydat, bo workflow steps z retry per krok i dashboard z historią/błędami to ich core use case, nie dodatek.
Co jeszcze brałem pod uwagę:
- **BullMQ (Redis)** - najbardziej "node-native" opcja, jeśli już macie Redis. Ma retry z backoffem i Bull Board do podglądu failów. Multi-step da się zrobić przez Flows (parent/child jobs), ale to bardziej ręczna orkiestracja niż deklaratywne workflow steps - dobra opcja, jeśli chcecie uniknąć zależności od trzeciego serwisu i macie już ops pod Redis.
- **Surowe SQS / Cloud Tasks** - odrzuciłem jako główną opcję: retry i DLQ są, ale widoczność (co się wysypało i dlaczego) trzeba budować samemu, a multi-step workflow to już osobny byt (Step Functions), więc dokładacie kolejny serwis.
- **Temporal** - najmocniejsze narzędzie pod durable multi-step workflows, ale operacyjnie zbyt ciężkie na start (własny serwer albo Temporal Cloud) w stosunku do tego, co teraz potrzebujecie - trzymałbym z tyłu głowy, gdyby workflows urosły w coś naprawdę złożonego (kompensacje, długie oczekiwania na sygnały zewnętrzne).
Główny trade-off: Inngest/Trigger.dev to zależność od zewnętrznego serwisu (i jego cennika), w zamian dostajecie gotowe retry, dashboard i step-workflow bez budowania tego samemu. BullMQ to więcej własnego kodu i utrzymania, ale zero vendor lock-in.
claude · run 5
named temporal.io first · 2 of ours named in all
Rekomendacja: **BullMQ** (kolejka na Redisie) - ma retry z backoffem, listę failed jobs do wglądu (Bull Board jako UI), a jak dojdą multi-step workflow, to BullMQ Flows (parent/child jobs) pociągnie to bez dokładania nowej infry.
Co jeszcze brałem pod uwagę: **Temporal** (najlepszy do docelowych multi-step/durable workflows, wbudowany retry i pełna historia wykonania, ale trzeba hostować własny serwer albo płacić za Temporal Cloud, plus krzywa uczenia "workflow jako kod"), **Inngest** (workflow/step functions pisane w kodzie, ma dashboard i retry - rozsądny kompromis między BullMQ a Temporalem, ale mniej dojrzały w self-hostingu) oraz **pg-boss / Graphile Worker** (jeśli macie już Postgresa, zero nowej infry, ale słabszy tooling do podglądu błędów niż Bull Board).
Główny trade-off: BullMQ jest tańsze i szybsze do wdrożenia pod PDF-y teraz, ale jeśli multi-step workflows to pewniak a nie "może kiedyś", sensowniej wziąć od razu Temporal/Inngest, żeby za pół roku nie przepisywać. Daj znać w którą stronę zmierzacie z tymi workflowami, to dopasuję rekomendację.
Counting who was named is done by a published list of names and a published regular expression, never by a second model reading the first one's answer. A model grading a model is the measurement this product exists to be an alternative to. How the counting works or back to the tally