Propojení Airtablu a Darujme.cz – malá případovka a ponaučení

[honzapav]

Ahoj všem!
Předělávám automatizaci z Make.com do n8n – důvod je jednoduchý. Je to poměrně náročné na operace a v n8n bude provoz levnější. Říkal jsem si, že si tu odložím pár poznámek z toho, co jsem se dneska naučil – pro svoje budoucí já a třeba i pro ostatní.

Varování – pokud s n8n nemáte zkušenosti, ta poslední část bude dost “heavy”. Popíšu ale i koncept a využití, ať si z toho každý něco odnese.

Jak to celé funguje?

Podstata je jednoduchá – potřebujeme každý den z Darujme.cz stáhnout aktuální transakce a uložit je do Airtablu. Oproti původnímu scénáři je teď potřeba transakce aktualizovat (třeba proto, že o víkendu transakce neprobíhají). Zdálo se to poměrně jednoduché, ale nebylo.

1. V první řadě musíme zjistit, zda už je dárce v naší databázi, a pokud ano, tak s ním tuto novou transakci spojit. Pokud ne, je potřeba ho vytvořit.
2. Pak je potřeba podle typu platby (pravidelná, opakující se) zařadit dárce do správného mailing listu. U existujících dárců je to složitější, protože nemůžu původní mailing listy přepsat – musím je spojit. Tady proběhne ještě optimalizace – je potřeba zajistit, aby dárce nebyl zároveň v mailing listu pro jednorázové i pravidelné dary.
3. Pak je potřeba najít, zda transakce v Airtablu existuje, a pokud ano, tak ji upravit. V opačném případě je potřeba ji vytvořit.

K čemu to slouží?

Organizace, pro kterou tohle realizuji, má skvělý přehled o svých dárcích: ty jednorázové navolává nebo jim posílá relevantní e-mailing s cílem získat si jejich přízeň pravidelně. S těmi pravidelnýmise také může bavit na jiné úrovni. Důvodů je celkově víc (hlavně vytvoření jednotné databáze kontaktů napříč projekty), ale tohle je podstata.

Co jsem si odnesl?

S n8n už pracuju přibližně rok a půl a přesto mám pocit, že občas narážím u věcí, které v Make.com dělám levou zadní. n8n má určitě strmější učící křivku, ale dnešek mě přesvědčil, že je to hodně o mindsetu. Nakonec to není tak odlišné a spousta věcí v Make.com ani nejde.

Tady je slibovaný seznam:

1. I když node Item list zajišťuje iterování (tzn. provedení dalších akcí pro každou položku), někdy se vyplatí použít Split in Batches a nastavit dávky “po jednom” (pak to funguje stejně jako Iterátor v Make.com). Hromadné operace se v Make.com téměř nedělají a v n8n jdou, ale někdy je to zbytečně komplexní.
2. Pokud používám node If, který řeší logickou podmínku (alternativa k Routeru v Make.com), a potřebuju později spojit dvě větve zpět do sebe, nepotřebuji Merge node. Dřív jsem to dělal. Přitom stačí do sebe větve spojit a funguje to naprosto automaticky.
3. I když mě uživatelské rozhraní editoru tlačít k mapování proměných pouze z předchozí node, je možné bez obav mapovat i dříve předcházející nodes. Jen je potřeba dávat pozor, abyste nepřerušili původní flow (např. dohledáváte neexistující data v Airtablu, node nevrátí nic a workflow může skončit). Všechno se ale dá řešit.
4. Práce spolemi (arrays) má v expression editoru stále rezervy – někdy je opravdu lepší napsat kousek Javascriptu v Code node.
5. Pokud potřebujete iterovat nad workflow, které je na konci hodně rozvětvené, stačí na konec přidat If node a do něj informaci z kontextu iterátoru Split in batches: {{$node["SplitInBatches"].context["noItemsLeft"]}}. Pokud je noItemsLeft = true, můžete workflow ukončit.

No – n8n určitě není pro každého, ale pokud vezmu v potaz, že jde o open source, který si můžete nainstalovat na vlastní server, může to být fajn řešení, třeba když pracujete s citlivými daty.

Kdyby vás cokoliv zajímalo, ptejte se!
H.

[jankolr]

Zajímalo by mě, jestli se taková migrace z Make na n8n vyplatí.

• Kolik předěláváš scénářů? Jak jsou komplikované? Máš tam třeba webhooky, data structures, data stores apod.?
• Kolik operací za měsíc spotřebuješ v Make? Jaký tam máš nastavený subscription plan?
• Jak náročné je vymyslet, jakým způsobem to přetransformovat z Make do n8n? Předpokládám, že to nemůžeš jen 1:1 překlikat…
• Kolik strávíš času s předěláním scénářů?
• Kolik stojí provoz n8n na vlastním serveru?

Asi tušíte kam tím mířím - pokud započteš svůj čas, který s tím strávíš, vyplatí se takovou migraci podstoupit? A udělal bys takové rozhodnutí znovu?
(mě by se do takové migrace určitě nechtělo )

[honzapav]

No, já to srovnání úplně nemám. Ten původní scénář v Make.com plnil svůj účel suboptiomálně a v tom novém nastavení by zase “hodně" žral, odhaduju několik tisíc operací na běh s tím, že se spouští “když je potřeba”.

Takže:

1. Přesouvám jeden scénář Je to jeden webhook, jedna minimalistická datová struktura, kterou ani nenahrazuji.
2. Mohlo by to klidně být 15-20 000 operací měsíčně. Osobně používám tarif Teams, ale je to bohužel overkill. Vlastně to vůbec nevyužiju (až na ty teamy). Make se mi letos podstatně zdražil.
3. Je to hodně jiné, ale vymyslet to složité není.
4. Po čase je moje rychlost stejná jako v Make.com, samozřejmě záleží na tom, co se dělá. Těžko se to dá zobecnit. Vlastně mě většinou brzdí jen klikání. Ale teď třeba řeším scénář, kde jsou potřeba složitější transformace v Javascriptu a to mi pořád docela trvá . Tady jsem se v několika věcech zasekl, a proto mi to trvalo cca 4 hodiny.
5. Já platím cca 100 dolarů měsíčně, dá se začít na 6 USD (hostuju u DigitalOcean – tady affil odkaz s kreditem 200 USD), ale je to kvůli jednomu projektu, kde protejká opravdu hodně dat. Jinak by mě to vyšlo levněji než n8n v cloudu (další affil odkaz, bacha ). Pro mě je teď klíčové ten server podstatně vytěžit, proto ho třeba poskytuji i dalším lidem. Popravdě – můj stav teď úplně ekonomický není. Náklady se zaplatí z projektů a nikoho to nestojí významně víc než Make.com. Ale hodně n8n věřím a beru ten čas strávený s tím jako investici.

Taky pak záleží na “obchodním modelu” – zrovna v tomhle případě (nedělám to často) beží všechno pod mým Make.com účtem a klient platí jiným modelem než za operace (ač máme nastavený nějaký strop). Když něco ušetřím, zůstane mi to. A n8n má pouze fixní náklady.

A jestli bych udělal to rozhodnutí znovu? Budu ho muset dělat – mám několik klientů, pro které je model platby za operace příliš nevýhodný. Jeden třeba platí přes 150 EUR měsíčně a n8n by to postatně snížilo.

Myslím, že předělávat věci 1:1 moc nedává smysl. Proto se snažím vždycky počkat na situaci, kdy se něco mění nebo předělává. A třeba vlastní automatizace už dělám defaultně v n8n.

Takže tak

[Pabu]

Hele, ja tomu fakt nerozumim. Proc na tohle nepouzijes Keboolu? Incrementy jsou totalne normal I easy vec, mas k tomu orchestraci a data v normalni dtb a ne locknuta v airtable. Plus takhle prtave veci mas cele v ramci freemium

[honzapav]

Ahoj Pavle , mám pro to tři důvody:

1. n8n.io používáme na mnohem víc věcí, takže radši využiju nástroj, který už ve stacku mám. S každým dalším nástrojem jsou spojené nějaké “náklady” mimo samotné náklady na provoz.
2. Musel bych se učit další nástroj – s těmi změnami v posledním roce (samozřejmě Keboolu sleduju) by to bylo nejspíš jednodušší, ale i tak mám omezenou kapacitu. Učící křivka low-code nástrojů jako je n8n byla v době, kdy jsem to řešil, sice podstatně vyšší než třeba u Make.com, ale pořád nižší než byla u Kebooly. S dnešní AI by to bylo taky jinak Zároveň i když se to dokážu naučit já, potřebuji, aby s tím dokázali pracovat i další lidi.
3. I když už dneska nepotřebuju, aby integrační platforma měla předpřipravené integrace (Airtable, Google služby apod.), pořád to hodně urychluje práci. n8n je kompatibilní se “světem”, který využíváme. Jsem si téměř jistý, že Airtable v integracích Kebooly v té době nebyl. Dokonce jsem kvůli tomu testoval Fivetran.

S Kristýnou jsem to tenkrát řešil (byl jsem respondent v testování) – zase tak velký rozdíl mezi Keboolou a n8n už není. Samozřejmě jsem o tom přemýšlel. Kdybys to chtěl někdy v detailu probrat a vidět, tak to můžeme projít. Každopádně v hledáčku Keboolu mám pořád, to se neboj

Každopádně díky za komentář!

Ještě UPDATE: ony to nakonec nejsou inkrementy, ale aktualizace řádků. Jsou potřeba kvůli aktualizaci stavu plateb.

[Pabu]

Jsou to dva ruzne architektonicke pristupy. Ten Tvuj, jak rika Padak “monoliticky” , vede k rychlu vysledku v komkretni problemu. Nicmene, lockuje do budoucna moznosti lehkeho rozsireni dalsich use casu ze stejne pipeliny. Coz muze byt naprosto fair, pokud je to vedomy trade off.