Egy workflow-eszköz gyorsabban elindul, az egyedi kód viszont hosszú távon olcsóbb lehet. Négy kérdés, amivel el lehet dönteni, melyik felé induljatok.
Ha két rendszert össze kell kötni, két úton lehet elindulni: egy workflow-eszközzel, mint az n8n vagy a Make, vagy egyedi kóddal a saját alkalmazásban. Mindkettő jó választás lehet, csak nem ugyanarra.
1. Hányszor fog lefutni?
Napi néhány tucat futásnál a workflow-eszköz kényelmes és olcsó. Ha viszont percenként több száz eseményt kell feldolgozni, az execution-alapú cloud árazás jelentős költséggé válhat; self-hosted környezetben pedig más költségmodell érvényesül.
2. Mennyire bonyolult a logika?
Az „ha beérkezik egy űrlap, küldj e-mailt és írd be a CRM-be" típusú folyamat pont a workflow-eszközök terepe. Amikor viszont a folyamatban elágazások, kivételkezelés, újrapróbálkozás és állapotkövetés is van, a vizuális szerkesztő átláthatatlanná válik. Egy húsz csomópontos folyamatábra könnyen nehezebben karbantarthatóvá válhat, mint ugyanaz a logika jól strukturált kódban.
3. Ki fogja módosítani?
Ez talán a legfontosabb kérdés. Ha a marketinges kolléga akarja állítgatni a leveleket, akkor a vizuális eszköz nyer, még akkor is, ha technikailag a kód lenne az elegánsabb. Ha viszont úgyis fejlesztő nyúl hozzá, akkor a kód mellett szól a verziókezelés, a code review és a tesztelhetőség.
4. Mi történik, ha elszáll?
Egy automatizáció akkor veszélyes, ha csendben hibázik. Kérdezd meg: honnan fogod tudni, hogy nem futott le? Van újrapróbálkozás? Hova kerülnek a hibás rekordok? Mindkét megoldásban meg lehet ezt oldani, de a workflow-eszközöknél gyakran kimarad, mert az alapfolyamat pár perc alatt összekattintható.
A gyakorlatban vegyesen szokott működni
A legtöbb ügyfelünknél nem választunk: a ritka, gyakran változó, üzleti oldalról szerkesztett folyamatok n8n-ben futnak, a nagy volumenű vagy kritikus adatmozgás pedig a saját alkalmazásban, tesztekkel. A kettő ugyanazon az API-n keresztül beszélget egymással.
Amit érdemes elkerülni
Azt, hogy egy prototípusnak indult workflow évekig éles üzleti folyamatot vigyen, dokumentáció és monitorozás nélkül. Ez a leggyakoribb ok, amiért egy automatizáció végül több munkát okoz, mint amennyit megspórolt.
