Files

T

JiriUhlirandClaude Opus 5 a57eca123e Fronta a worker: webhook odpovi hned, praci udelaji workeri

Webhook uz nic nevykonava v requestu. Zapise udalost do fronty a odpovi 202
do jednotek milisekund; strom vykona worker na pozadi. Za konektory nerucime,
takze cekat na cizi sluzbu v requestu znamena ztracet udalosti pri timeoutu.

Fronta ma opakovani s rostouci prodlevou (30 s, 2 min, 10 min, hodina),
spravedlive poradi po firmach (jedna firma s tisicem udalosti nezablokuje
ostatni), navrat zaseknutych behu po restartu a uklid hotovych. Marna chyba
se neopakuje - chybejici skript za minutu existovat nezacne.

Tri druhy spoustecu: push (webhook), vnitrni udalost (vznik a zmena ticketu)
a pull, tedy pravidelne dotazovani u sluzeb bez webhooku (posta, zpravy).
Planovac jen rekne "je cas", samotny dotaz je prvni krok stromu, takze ma
zaznam v logu a opakuje se pri chybe jako cokoliv jineho.

Kontrakt tela webhooku: kazdy parametr ma cestu (data.order.id,
errors.0.message), takze jde napojit i odesilatel s vnorenym modelem.
U adresy je metoda, ukazka tela a kopiruje se cela adresa vcetne domeny.

Vnitrni kroky, ktere sahaji do naseho uloziste: ticket/upsert (zaloz nebo
dopln podle externiho ID), assign-least-busy, assign-by-external, set-type,
set-stage, add-tags, set-status, incident/create, flow/pause a flow/log.

Faze ticketu jako treti osa vedle stavu a stitku. Stav je zivotni cyklus
a pocitaji se z nej statistiky, faze je workflow daneho typu a muze byt jen
jedna, takze se na ni da spolehnout v podmince.

ID z cizich aplikaci u resitele: voicebot posle voicebotId a ticket skonci
u toho, komu patri. Vazba je na jednom miste, ne v kazde automatizaci.

Kazda chyba zaklada incident se dvema urovnemi: impact cte klient a je
srozumitelny, detail cte admin a je v nem cely beh, ktery krok selhal, cele
hlaseni a data na vstupu. Detail vidi jen spravce platformy.

Ochrana proti smycce: automatizace navazana na zmenu ticketu ticket meni,
cimz se spousti znovu - pri vyvoji to server polozilo. Resi to oznaceni behu
pres AsyncLocalStorage a strop peti behu na jeden ticket za minutu.

Upozorneni pri prideleni prace vcetne cisla u zalozky Tickety. Zivy dashboard:
dlazdice nad nasimi daty na udalost, data z konektoru podle ttlSec s moznosti
vynutit nacteni znovu.

Opraveno: path a intervalSec u spoustece se pri ulozeni zahazovaly; nad
seznamem neslo pouzit contains, takze na stitky neslo postavit podminku;
novejsi vystup kroku ted prekryje starsi misto hlaseni konfliktu.

Overeno dvema scenari proti bezicimu serveru, 34 kontrol: firma se skladem,
expedici a IT, a hovory z voicebota (callSid do externiho ID, status do faze,
prirazeni podle voicebotId, tri zpravy = jeden ticket se tremi udalostmi).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-13 16:41:02 +02:00

9.0 KiB

Raw Blame History

01 - Prehled a stav

Co aplikace je

Web a klientsky portal IT firmy. Verejna cast prodava sluzbu, cast za prihlasenim ukazuje klientovi stav jeho automatizaci, ticketu a incidentu.

Vse je jedna aplikace v jednom containeru. Express obsluhuje API i zbuildovanou React aplikaci ze slozky dist/public.

Stav

Oblast	Stav	Poznamka
Verejny web	hotovo	homepage, sluzby, o nas, kontakt, 404
Prihlaseni	hotovo	JWT, demo ucty
Dashboard	hotovo	prehled, tickety, incidenty, automatizace, nastaveni
Zivy dashboard pres SSE	hotovo	zmeny se projevi bez obnoveni stranky
Katalog sluzeb	hotovo	29 sluzeb, 7 kategorii vcetne Obecne
Builder automatizaci	hotovo	strom akci, vetveni podminkou
Webhook s registrovanou adresou	hotovo	token generuje server, verejny endpoint validuje data
Tickety na konkretni lidi	hotovo	resitel, filtr moje, prehled vytizeni tymu
Prijem udalosti do ticketu	hotovo	webhook na firmu, externi ID unikatni za firmu
Udalosti na ticketu	hotovo	dalsi zprava se navesi na tentyz ticket
Statistiky resitelu	hotovo	odbaveno, mediany casu, vracene, fronta
Pohledy tabulka a dlazdice	hotovo	tickety i lide
Stranka Lide a detail osoby	hotovo	vykon a co ma u sebe
Log ticketu ve strome	hotovo	vcetne toho, co ktera sluzba vratila
Kanaly do ticketu	hotovo	WhatsApp, e-mail, hlas a formular jako spoustece
Parametry od sluzby	hotovo	katalog je deklaruje, server je dosazuje pri ulozeni
Nastaveni poli akci	castecne	ticket, e-mail a WhatsApp ano, ostatni jen napoveda
Obsah ticketu a sablony	hotovo	`{{parametr}}` ze spoustece do poli akce
Vystupy kroku a predvalidace	hotovo	podminka se umi zeptat, co vratil predchozi krok
Kanaly WhatsApp, FB, Instagram	hotovo	vcetne vzorovych automatizaci na prijem
Firmy a prava	hotovo	tri pohledy, uzivatel muze byt ve vic firmach
Nastavitelny dashboard	hotovo	widgety, sirky a poradi, ulozene za uzivatele a firmu
Skripty konektoru	hotovo	manifest, kontrola parametru, hot reload, iDoklad
Konektory za firmu	hotovo	pristupove udaje v konektoru, overeni napojeni
Transformace dat	hotovo	pravidla i sablona JSON, kroky si predavaji struktury
Sprava clenstvi z portalu	hotovo	uzivatele, firmy a role v Nastaveni
Role a prava jako data	hotovo	26 prav v katalogu, vlastni role za firmu
Zalozky a limity za firmu	hotovo	navigace chodi ze serveru, ne z kodu klienta
Osoby a skupiny resitelu	hotovo	ticket lze prehodit na skupinu, ne jen na cloveka
Typy ticketu a vlastni pole	hotovo	typ rozhoduje, ktere akce se na ticketu ukazou
Vydefinovane akce na ticketu	hotovo	vazba na typ nebo tag, telo je operace, strom, skript
Vlastni widgety	hotovo	vcetne zdroje z konektoru a vykonu resitelu
Telo akce jako strom	hotovo	tentyz editor jako automatizace
Audit a prepnuti na jiny ucet	hotovo	prepnuti je vychozi jen pro cteni, vse v auditu
Bugs a wishes	chybi	vyvojarska agenda, samostatna evidence vedle ticketu
Beh automatizaci	hotovo	fronta, worker, opakovani, ochrana proti smycce
Prijem udalosti do fronty	hotovo	webhook odpovi 202, praci dela worker
Pravidelne dotazovani sluzeb	hotovo	planovac pro postu a zpravy, perioda u spoustece
Upozorneni na pridelenou praci	hotovo	cislo u zalozky a hlaska v portalu
Incident z chyby	hotovo	popis pro klienta, podrobnosti pro admina
Uloziste konektoru	hotovo	Postgres, nebo JSON soubor. Udaje vzdy sifrovane
Uloziste pro zbytek	hotovo	tickety, automatizace, incidenty, rozlozeni, entity
Monetizace a cena za krok	navrh	popis v 16-monetizace.md, neni naprogramovane
Odesilani e-mailu z formulare	chybi	poptavka se zatim jen loguje

Znama omezeni

Data prezijou restart, ale ne redeploy, kdyz neni databaze. Rezim se pozna v portalu i v /health/ready a rozhoduje o nem jedno misto, viz 14-databaze.md:

Rezim	Kdy	Nasledek
`postgres`	je `DATABASE_URL` a migrace prosly	data se neztraci
`file`	neni databaze, je `DATA_DIR`	prezije restart, ne redeploy
`memory`	neni ani `DATA_DIR`	ztrati se pri restartu

Beh automatizaci uz existuje, ale je synchronni v requestu: webhook ceka, nez cely strom dobehne, a pri padu procesu se rozdelany beh ztrati. Neni fronta ani opakovani. Co to znamena pro vetsi provoz a co s tim, je zmerene v 19-kapacita-200-firem.md, navrh fronty v 10-runtime-a-kapacita.md.

Obsah verejneho webu je ukazkovy. Nazev firmy, reference, tym i cisla jsou vymyslene a pred ostrym pouzitim se musi nahradit. Firemni udaje jsou na jednom miste v web/src/config/brand.ts.

Zivy stream drzi seznam posluchacu v pameti jedne instance. Pri vice instancich by ho musel nahradit sdileny kanal, napriklad Redis pub/sub.

Log ticketu uz plni skutecny beh: kazdy krok stromu se do nej zapise vcetne toho, co sluzba vratila. Ukazkova sada ticketu ma log psany rucne, aby bylo co ukazat i na prazdne instanci.

Dalsi krok

Nejuzitecnejsi pristavek je runtime. Strom uz nese vsechno potrebne: spoustec s parametry, podminky a u ticketu i kanalu nastavena pole se sablonami. Chybi jen to, co ho vykona. Do te doby je ulozena automatizace popis zameru, ne provoz.

Vedle toho zbyva prevest na inputs i ostatni konektory a doplnit odkazy na vystup predchoziho kroku, ne jen na spoustec. Podrobnosti v 05-dashboard-a-builder.md.

Za rozmysleni stoji evidence bugs a wishes. Zamerne to nejsou tickety, duvod je v 06-tickety.md.

Prvni cast navrhu uz je hotova: vykonna cast konektoru, tedy skripty s manifestem a kontrolou parametru, viz 11-skripty-konektoru.md. Runner je pripraveny, chybi nad nim fronta.

Datove modely a prava z 09-navrh-rozsireni.md jsou hotove, popis stavu je v 17-nastaveni-a-prava.md. Navrh k rozhodnuti zustava 10-runtime-a-kapacita.md pro frontu, beh kroku a rozpocet na 150 klientu, a 16-monetizace.md pro cenu za krok.

Dokumentace

Soubor	O cem
02-appfactory-proxy.md	beh za reverse proxy, ROOT_PATH, health
03-architektura-a-mapa-kodu.md	kde co je
04-api.md	endpointy a to, co ze Swaggeru neni videt
05-dashboard-a-builder.md	editor automatizaci
06-tickety.md	model ticketu a log prubehu
07-firmy-a-prava.md	firmy, pohledy, kdo co vidi
08-dashboard-widgety.md	nastavitelny prehled
09-navrh-rozsireni.md	puvodni navrh rozsireni
10-runtime-a-kapacita.md	navrh: fronta, beh kroku, kapacita
11-skripty-konektoru.md	vykonna cast sluzeb
12-sluzby-a-konektory.md	sluzba, konektor, viditelnost
13-transformace-dat.md	pole na pole a JSON na JSON
14-databaze.md	tri rezimy uloziste, migrace, sifrovani
15-rejstrik-funkci.md	k cemu je jaka funkce a komponenta
16-monetizace.md	navrh: cena za krok a balicky
17-nastaveni-a-prava.md	prava, typy, akce, widgety, prepnuti uctu
18-ticketovaci-system.md	udalosti, externi ID, statistiky, pohledy
19-kapacita-200-firem.md	zmereno, co zvladne soucasny stav
20-fronta-a-runtime.md	fronta, worker, spoustece, ochrana proti smycce
99-zmeny.md	zaznam zmen, nejnovejsi nahore

9.0 KiB Raw Blame History