Zum Hauptinhalt springen
Zurück zu den Einblicken
Von 39 Aufrufe

Warum ich für n8n einen eigenen nativen Client entwickle

Kurz gesagt: n8n ist für mich längst mehr als ein Werkzeug zum Ausprobieren von Automatisierungen. Mehrere selbstgehostete Instanzen gehören inzwischen zu meiner eigenen Infrastruktur und zu unterschiedlichen Projekten. Mit Calenode entwickle ich deshalb einen nativen Client für iPad und Mac, der mir genau den Zugriff ermöglicht, den ich im Alltag vermisst habe.

Warum ich für n8n einen eigenen nativen Client entwickle

Viele meiner Projekte beginnen nicht mit der Frage, ob daraus irgendwann ein eigenes Produkt werden könnte.

Sie beginnen wesentlich einfacher:

Mir fehlt etwas.

Bei Calenode war es genauso.

n8n gehört inzwischen fest zu meiner Arbeit. Ich nutze es für Automatisierungen und betreibe mehrere selbstgehostete Instanzen für unterschiedliche Projekte und Aufgaben.

Die eigentlichen Workflows lassen sich über die Weboberfläche von n8n erstellen und verwalten. Das funktioniert und daran möchte ich auch nichts ersetzen.

Trotzdem stellte ich im Alltag fest, dass mir etwas fehlte.

Ich möchte nicht jedes Mal den Browser öffnen, die entsprechende Instanz aufrufen und mich durch eine vollständige Weboberfläche bewegen müssen, nur um beispielsweise nachzusehen, ob eine Instanz erreichbar ist oder was dort gerade passiert.

Gerade wenn mehrere selbstgehostete Instanzen hinzukommen, wird aus einem einzelnen n8n-System irgendwann eine kleine Infrastruktur.

Und genau an diesem Punkt entstand die Idee für Calenode.

Nicht n8n ersetzen, sondern den Zugriff darauf verändern

Calenode soll kein eigener Workflow-Editor und schon gar kein Ersatz für n8n werden.

Das wäre aus meiner Sicht auch am eigentlichen Problem vorbeientwickelt.

n8n besitzt bereits eine umfangreiche Oberfläche für die Erstellung und Verwaltung von Workflows. Mein Bedarf liegt an einer anderen Stelle: Ich möchte meine Instanzen auf meinen Apple-Geräten möglichst direkt erreichen und wichtige Informationen schnell abrufen können.

Also entstand die Idee eines nativen Clients.

Eine Anwendung, in der ich meine verschiedenen n8n-Server hinterlegen kann und anschließend nicht mehr darüber nachdenken muss, welche URL zu welcher Instanz gehört.

Server auswählen.

Verbinden.

Informationen abrufen.

Und später weitere Verwaltungsfunktionen dort ergänzen, wo sie im mobilen oder nativen Einsatz tatsächlich sinnvoll sind.

Das klingt zunächst nach einem kleinen Unterschied.

Für mich ist es aber genau die Art von Unterschied, aus der häufig gute Software entsteht.

Warum überhaupt eine native App?

Natürlich hätte ich auch eine weitere Webanwendung entwickeln können.

Technisch wäre das vermutlich sogar der naheliegendere Weg gewesen.

Bei Calenode habe ich mich trotzdem bewusst für eine native Anwendung mit SwiftUI entschieden.

Mein Mac, mein iPad und meine anderen Apple-Geräte sind meine täglichen Arbeitsgeräte. Wenn ich eine Anwendung regelmäßig verwende, möchte ich deshalb auch, dass sie sich wie ein Bestandteil dieser Umgebung verhält.

Eine native Anwendung muss für mich nicht versuchen, die komplette Weboberfläche eines Systems auf einen kleineren Bildschirm zu übertragen.

Im Gegenteil.

Sie sollte sich auf die Informationen und Funktionen konzentrieren, die in der jeweiligen Situation tatsächlich benötigt werden.

Gerade auf dem iPad ist das wichtig.

Ich möchte dort nicht zwangsläufig einen komplexen Workflow mit zahlreichen Nodes bearbeiten. Dafür ist ein großer Bildschirm schlicht das bessere Werkzeug.

Aber schnell überprüfen, was auf einer Instanz passiert?

Einen Server auswählen?

Informationen zu einer Instanz abrufen?

Oder später bestimmte administrative Aktionen durchführen?

Dafür kann eine native App sehr sinnvoll sein.

Self-Hosting gehört für mich dazu

Ein weiterer Punkt war von Anfang an wichtig:

Calenode entsteht mit Blick auf selbstgehostete n8n-Instanzen.

Ich betreibe meine eigenen Systeme und möchte selbst entscheiden können, wo meine Daten liegen und wie meine Infrastruktur aufgebaut ist.

Das bedeutet nicht, dass jede Software grundsätzlich selbst gehostet werden muss.

Aber wenn ich mich bewusst für Self-Hosting entscheide, möchte ich diese Systeme anschließend auch vernünftig verwalten können.

Bei einer einzelnen Instanz ist das relativ einfach.

Bei mehreren Instanzen verändert sich die Situation.

Eine kann zu einem bestimmten Projekt gehören, eine andere zu einer internen Automatisierung und wieder eine andere zu einer separaten Umgebung.

Dann wird Übersicht zunehmend wichtiger.

Genau dort soll Calenode ansetzen.

Die erste Version muss nicht alles können

Eine der schwierigsten Entscheidungen bei eigenen Projekten ist für mich immer wieder dieselbe:

Was gehört wirklich in die erste Version?

Es gibt schnell sehr viele Ideen.

Wenn eine Serverübersicht vorhanden ist, könnte man noch diese Information anzeigen. Wenn die Verbindung zur API funktioniert, könnte man auch jene Funktion integrieren. Und wenn man ohnehin gerade dabei ist, könnte man doch gleich noch etwas anderes ergänzen.

Auf diese Weise wächst aus einer überschaubaren Anwendung sehr schnell ein Projekt, das niemals fertig wird.

Bei Calenode versuche ich deshalb bewusst, den Kern im Blick zu behalten.

Zunächst muss die grundlegende Verwaltung der n8n-Instanzen zuverlässig funktionieren.

Server hinzufügen.

Server anzeigen.

Eine Instanz auswählen.

Eine Verbindung herstellen.

Informationen strukturiert darstellen.

Erst wenn diese Grundlage funktioniert, ergibt es Sinn, weitere Funktionen darauf aufzubauen.

Das klingt in der Theorie selbstverständlich.

In der Entwicklung ist es erstaunlich leicht, diesen Grundsatz aus den Augen zu verlieren.

Eine App für einen Bedarf, den ich selbst habe

Calenode ist deshalb auch ein gutes Beispiel dafür, wie ich Software gerne entwickle.

Nicht zuerst eine möglichst lange Featureliste schreiben und anschließend versuchen, dafür ein Problem zu finden.

Sondern mit einem konkreten Bedarf beginnen.

Ich betreibe mehrere n8n-Instanzen.

Ich möchte diese einfacher über meine Apple-Geräte erreichen und verwalten.

Die vorhandene Weboberfläche bleibt dabei genau dort im Einsatz, wo sie ihre Stärken hat.

Und für die Situationen, in denen ich einen schnelleren und nativeren Zugriff möchte, entsteht Calenode.

Ob daraus am Ende eine Anwendung wird, die ausschließlich meinen eigenen Arbeitsalltag verbessert oder auch anderen Nutzern selbstgehosteter n8n-Instanzen hilft, wird sich zeigen.

Aber genau das macht die Entwicklung für mich interessant.

Calenode entsteht nicht, weil ich unbedingt noch eine App entwickeln wollte.

Calenode entsteht, weil mir bei meiner täglichen Arbeit eine gefehlt hat.
Der nächste Schritt: die Veröffentlichung im Apple App Store.

Themen

Beitrag teilen

Weitere Einblicke