Andrey Gershengoren · · 5 min
n8n ist ein gutes Werkzeug, solange die Aufgabe in fertige Nodes passt. Interessant wird es dort, wo sie nicht mehr passt. In einem Videoprojekt bin ich an diese Stelle geraten, und sie hat mich überrascht. Entschieden hat, was die Aufgabe von der Laufzeitumgebung verlangte; die Logik dahinter blieb die ganze Zeit über einfach. Dieser Beitrag beschreibt den Fall und die Entscheidung, die daraus folgte.
Für eine Nachrichtenplattform auf Telegram habe ich eine Pipeline gebaut, die Textnachrichten in Videos umwandelt: Ein Avatar-Moderator liest die Nachricht vor. Die Orchestrierung lief in n8n als managed Instanz, die Videogenerierung über eine externe API.
Das Problem lag danach. Die generierten Videos mussten auf ein einheitliches Format gebracht werden, und Zuschneiden allein reichte dafür nicht. Der Moderator sollte nach dem Zuschnitt im Bild zentriert bleiben, unabhängig davon, wo sein Gesicht im Ausgangsvideo lag. Damit hängt der Zuschnittsbereich vom Inhalt des Videos ab und lässt sich nicht vorab als fester Wert hinterlegen.
Auf einer self-hosted Instanz ließe sich ffmpeg über Execute Command oder eine Code-Node ansprechen. Auf der managed Instanz stand dieser Weg nicht offen: keine eigenen Binaries, kein Zugriff auf das Dateisystem der Umgebung.
Aber auch unabhängig davon wäre n8n der falsche Ort gewesen. Videoverarbeitung ist eine langlaufende, CPU-intensive Aufgabe. Eine Workflow-Engine ist dafür nicht gebaut: Timeouts, keine sinnvolle Testbarkeit, keine Kontrolle über Ressourcen.
Hier verläuft die Grenze von Low-Code: bei den Anforderungen an die Laufzeitumgebung, nicht bei der Komplexität der Logik. Ein Workflow darf verzweigen, Fälle unterscheiden und Dienste verbinden, solange jeder einzelne Schritt kurz ist und wenig Ressourcen braucht. Läuft ein Schritt Minuten und lastet eine CPU aus, lässt er sich zwar weiterhin im Workflow ausdrücken, aber die Umgebung ist für diese Art Arbeit nicht gebaut.
Zum Projekt gehörte bereits ein Strapi-Backend auf einem VPS. Ich habe dort einen Endpoint ergänzt, der ein Video entgegennimmt, verarbeitet und zurückgibt. n8n ruft diesen Endpoint als einen Schritt im Workflow auf.
Die Verarbeitung selbst besteht aus drei Teilen. ffmpeg wurde dem Docker-Image als Systempaket hinzugefügt. fluent-ffmpeg kommt als Node-Wrapper dazu; die Bibliothek ersetzt kein ffmpeg, sie spawnt es als Kindprozess. Der Gewinn liegt in der Ergonomie: lesbare API statt handgebauter Argument-Strings, Events für Fortschritt und Fehler. face-api.js übernimmt die Gesichtserkennung. Aus der Position des Gesichts wird der Zuschnittsbereich berechnet, sodass der Moderator im Zielformat zentriert ist.
Eine eigenständige Alternative gab es: einen separaten Worker mit Queue. Ich habe sie verworfen. Das Volumen der Plattform rechtfertigte keine zusätzliche Infrastruktur mit eigenem Deployment und eigenem Monitoring. Der bestehende Backend-Prozess war der richtige Ort für diese Aufgabe, zu diesem Zeitpunkt, bei diesem Volumen.
Der Zusatz am Ende ist keine Floskel. Er ist die Bedingung, unter der die Entscheidung gilt.
Gekauft habe ich Einfachheit: keine neue Infrastruktur, ein Deployment statt zwei, eine Lösung in Tagen statt Wochen. Bezahlt habe ich mit Kopplung.
Videoverarbeitung und CMS teilen sich einen Prozess, und Last auf der einen Seite ist damit Last auf der anderen. Jede Änderung an der Videologik bedeutet ein Deployment des gesamten Backends. Und es gibt keine Fehlerisolation: Eine fehlerhafte Eingabedatei, die den ffmpeg-Prozess zum Absturz bringt, gefährdet nicht einen Videoservice, sondern das Backend.
Der letzte Punkt ist der unangenehmste, weil er die Redaktion trifft und nicht die Technik. Ein Video, das nicht erzeugt wird, ist ein ausgefallener Beitrag. Ein Backend, das dabei mitgeht, ist eine ausgefallene Plattform. Diese Risiken waren bekannt und wurden bewusst akzeptiert.
Die Lösung trägt, solange zwei Bedingungen gelten: Es existiert bereits ein Node-Backend, und das Verarbeitungsvolumen bleibt klein genug, dass es nicht mit der Hauptlast des Backends konkurriert. Fällt eine der beiden weg, war es die falsche Entscheidung, und zwar rückwirkend.
Wächst das Volumen darüber hinaus, ist der nächste Schritt klar: die Verarbeitung in einen separaten Worker mit Queue auslagern. Die Endpoint-Schnittstelle bleibt dabei unverändert, was den Umbau begrenzt. Der Aufruf aus n8n weiß nicht, wer auf der anderen Seite antwortet, und muss es auch nicht wissen. Der abgelehnte Weg ist damit vertagt, nicht verworfen.
Für den Low-Code-Kontext heißt das: n8n orchestriert, aber es rechnet nicht. Das ist dieselbe Grenze, die ich an anderer Stelle als Grenze der Zuständigkeit beschrieben habe, nur von der anderen Seite betrachtet. Dort ging es um Logik, die zu groß für einen Funktionsknoten wird. Hier geht es um Arbeit, die zu schwer für die Umgebung wird.
Wer Code schreiben kann, behandelt die Workflow-Engine als das, was sie ist: ein Dirigent, kein Orchester.
In einem Abendprojekt bewertet ein Agent den Umgangston des Nutzers und führt darüber Buch. Die Bewertung macht das Modell, die Buchhaltung ein Python-Skript. Warum diese Grenze die eigentliche Architekturentscheidung ist.
· 5 min
Generierter Code scheitert selten sichtbar an fremden Bibliotheken. Er benennt Methoden, die es nicht mehr gibt, und Versionen, die es nie gab. Dagegen hilft kein genaueres Lesen, sondern eine Quelle, die nicht das Modell ist.
· 7 min
Sie beschreiben die Lage, ich sage, ob und wie ich helfen kann. Ohne Folien, ohne Verkaufsgespräch.