Graf závislostí nepíšeš, ten už v kódu je
Orchestrátory typu Airflow po tobě chtějí, abys nakreslil orientovaný acyklický graf úloh a business logiku pak schoval dovnitř uzlů. Ta věta obsahuje celý problém: abstraktní syntaktický strom tvého kódu už DAG je. Sekvenci, větvení i paralelismus jazyk vyjadřuje od začátku. Nakreslit je podruhé ve zvláštním souboru není abstrakce, je to duplicita.
Pravý problém durable execution leží jinde a je nudnější. Ne jak vyjádřit závislosti, ale kde jsou trvanlivé hranice, za kterými se výsledek už neztratí.
Kde se hranice bere
Workflow SDK řeší zápis direktivami v běžném TypeScriptu. "use workflow" označí orchestrační logiku, "use step" označí operaci s vedlejším efektem. Kompilátor podle nich zdroják rozdělí na oddělené bundly a graf řízení odvodí přímo ze struktury kódu.
Ta hranice není kosmetická. Krok svůj výsledek před pokračováním potvrdí přes frontu do databáze, čímž vznikne checkpoint. Po pádu se orchestrace přehraje a hotové kroky se místo znovuspuštění načtou.
To je stejný princip, jaký znáš z "use client" a "use server". Direktiva neoznačuje styl kódu, ale místo, kde se láme prostředí běhu. Tady se neláme klient a server, ale to, co se přehrává, a to, co se smí provést právě jednou.
Verzování je ta část, která bolí
Nejcennější kus textu je přiznání o Temporalu. Změníš kód, zatímco běhy jsou rozpracované, přehrání narazí na starou historii událostí a spadne na nedeterminismus. Oficiální řešení je patchovací API s příznaky verzí, po kterém se v kódu hromadí mrtvé větve, dokud neshnije.
Vercel to obchází tím, že běh připne na deployment, který ho spustil. Běžící workflow tedy dojede proti kódu, se kterým začalo, i po několika nasazeních.
Stojí za to všimnout si, čím se za to platí. Tohle řešení není algoritmus, je to důsledek neměnné historie deploymentů. Jinde ho zadarmo nedostaneš, což autor otevřeně přiznává. Když si stavíš vlastní orchestraci nad Postgresem, otázka „proti jakému kódu doběhne to, co běží teď" zůstává tvoje.
Cena za hranici
Přiznaná slabina je přesně tam, kde ji čekáš. Každé volání kroku znamená síť a průchod frontou, protože jinak se výsledek trvanlivě nezapíše. Deklarovaný cíl zní, že kroky mají být zadarmo, a zatím zadarmo nejsou.
Z toho plyne návrhové pravidlo, které platí bez ohledu na knihovnu. Granularita kroku je rozpočtové rozhodnutí, ne estetické. Příliš jemné kroky platíš latencí u každého z nich, příliš hrubé platíš tím, že se po pádu přepočítá velký kus práce. Nejde o to, kde je hranice hezká, ale kolik stojí ztráta práce mezi dvěma checkpointy.
Co si z toho odnést
Až budeš příště vybírat nástroj na dlouhoběžící procesy, přestaň porovnávat, jak se v něm kreslí graf. Ptej se na tři věci: kde vzniká checkpoint, co se stane s běžícími procesy po nasazení nové verze a kolik stojí jeden krok navíc.
Direktivy jsou tu použité chytře, ale nejsou to kouzlo. Jen přesouvají rozhodnutí o hranici běhu z konfigurace do místa, kde se ta hranice fakticky nachází, tedy do kódu vedle logiky, které se týká.
A jednu věc si z toho odnes, i když žádný workflow engine nenasadíš. Kdykoli tě nástroj nutí popsat strukturu, kterou tvůj kód už má, ptej se, co skutečně přidává. Někdy trvanlivost nebo viditelnost. Často jen druhé místo, které se rozejde s tím prvním.