Kontrollera dina webbplatsens backlänkar i n8n eller i ett vanligt Python-skript?

När en visuell flow förtjänar sin plats

En canvas är värd sin röra i vissa jobb. Om en icke-teknisk person behöver se varje steg och dess senaste körning, slår en visuell flow ett repo som de aldrig kommer att öppna. Håll det kort.

De flesta backlänksjobb är en hämtning, en kontroll och en skrivning. Fyra noder gör det bra. Om ditt jobb är att kontrollera dina webbplatsens backlänkar varje månad för en kund, passar den formen en canvas. Problemet börjar när någon lägger till paginering, retries och en diff, eftersom varje en ger sin egen gren.

Välj canvasen för läsaren, inte författaren.

Vem läser flödet

Marknads- och säljfolk läser en flow efter dess utdata, och de vill se den senaste körningen rakt fram. En canvas ger dem det utan en ticket. De läser utdata, inte koden. Ett skript ger dem en loggfil som de inte kommer att öppna.

Ge flödet ett tydligt namn och en enradig beskrivning, så att nästa läsare vet vad det lovar innan de öppnar det. En nod med en vag etikett kostar mer tid än någon saknad funktion.

Grenar du kan se på en glimt

En IF-nod på ok är lätt att följa. Tre av dem på en sida är fortfarande läsbara, om varje gren har ett enkelt namn. Därefter korsas linjerna, och en granskare behöver tio minuter för att vara säker på vilken gren som triggar vid ett tomt resultat.

Var en canvas blir en tillgång

Loopar över många domäner, delat tillstånd mellan körningar och enhetstester är de vanliga tryckpunkterna. En canvas hanterar varje en med en workaround, och varje workaround är en plats där flödet kan sväva från vad du menade.

Om du märker att du exporterar JSON för att fixa en flow, har jobbet överväxt canvasen. Flytta logiken till kod och behåll canvasen för aviseringen.

n8n-uppsättningen på fyra rader

En HTTP Request-nod, metod GET, URL https://linkzoid.pro/api.php. Lägg till query-parametrar action, q, key. Varje som vill kontrollera dina webbplatsens backlänkar på detta sätt kan kopiera det på fem minuter.

Spara nyckeln i credentials, inte i noden. Lägg till en IF-nod på ok, och skicka den falska grenen till ett error workflow som pingar dig.

Dela rows-arrayen med en Item Lists- eller Split Out-nod, skriv sedan till Google Sheets eller Postgres. Håll koll på execution counts, eftersom varje item kan faktureras som ett steg på vissa planer.

Det är hela jobbet. Det går sönder när paginering kommer: loopar i n8n fungerar men läses dåligt bortom cirka tio noder.

Kostnad per körning

På vår sida är kostnaden densamma oavsett: 2 credits för en refdomains-sida. Byggaren är där kostnaderna skiljer sig.

En self-hosted n8n är gratis att köra. Cloud planer räknar executions. Ett vanligt skript på cron kostar ingenting.

Oavsett vad du väljer, behåll en daterad kopia av varje körning utanför verktyget. Veckosammanfattningar i Actions är en städat ställe för det, och suite jämförelsen förklarar varför din egen historik är värd att ha.

Räkna executions per domän

En loop över fyrtio domäner är fyrtio körningar på en plan som räknar executions. Kontrollera hur din plan räknar en loop innan du lägger den på ett schema, eftersom fakturan följer count, inte credits.

Skriv den förväntade count bredvid schemat. En överraskning på fakturan är lättare att förklara när uppskattningen redan var i filen.

Self-hosting har sin egen faktura

En self-hosted n8n kostar servern, uppgraderingarna och backuper. Databasen är din att hålla vid liv. Ett vanligt skript på en liten maskin har färre rörliga delar, vilket är en anledning att välja det för ett fast månadsjobb.

Vad som brukar gå sönder först

I n8n är det paginering och item counts. I Python är det det ingen testade: en tom rows, en timeout, ett fält som heter annorlunda än du antog.

Inget verktyg är fel. Välj efter vem som underhåller det om sex månader. Om det är du, ensam, är kod lättare att grep:a. Om det är ett marknadsföringsteam som redan bor i canvasen, slår en liten flow de kan se ett repo de fruktar.

Blandade uppsättningar fungerar också. Låt Python skriva CSV på ett schema och låt n8n läsa filen och posta till Slack. Varje verktyg gör den del det hanterar bäst, och ingen flow växer bortom tio steg.

Att hålla Python-versionen läsbar

Det vanliga fallet för kod är att någon annan måste ändra det om sex månader. Gör det enkelt. Ett kort skript med tydliga namn och en sparad response slår en smart one-liner som ingen vågar röra.

Testa parsaren på en sparad response

Spara en verklig response till en fil och peka en unit test på den. Parsaren kör då utan att spendera en credit, och ett döpt fält misslyckas i testkörningen istället för på måndagsmorgonen.

Håll den sparade response liten, eftersom ett dussintal rader räcker. Notera datumet du tog den, så att du vet när fältnamnen senast ändrades.

Håll inställningarna på ett ställe

Domäner, actions och sidstorlek hör hemma i en liten config-block, inte utspridda över skriptet. En kollega kan då ändra mållistan utan att röra logiken som parserar raderna.

Håll secrets utanför den blocken också. Ladda dem från environment, på samma sätt som nyckeln laddas.

Kör en tvåveckors provperiod innan du bestämmer dig

Luta dig inte på papperet. Bygg den minsta versionen av jobbet i varje verktyg, kör det varje dag i två veckor, och se vilken du öppnar utan att bli ombedd.

Titta på vad som går sönder. Räkna gångerna du behövde redigera något för hand, och gångerna output var fel utan ett error. Verktyget som kräver färre handfixar är det du ska behålla.

Logga varje manuell fix

Håll en vanlig anteckning om varje gång du rörde flödet eller skriptet för hand. En kort lista efter två veckor berättar mer än någon funktionsbord någonsin kommer att göra.

Notera vem som bad om ändringar

Om förfrågningarna kom från personer som inte kan läsa kod, kan canvasen vinna. Om de kom från dig, är repo lättare att leva med.

Båda svaren är bra så länge du kan peka på det. Skriv anledningen bredvid flödet eller repo, och gå tillbaka till det när jobbet växer.