Directus kam und ging

Es gab eine Phase, in der ich Inhalte pflegen wollte, ohne dafür Code zu ändern: Ankündigungen, Hilfetexte, Bilder, kleine Seiteninhalte. Der klassische Fall für ein Content-Management-System, und ich habe ein fertiges genommen — Directus, weil es auf einer bestehenden Datenbank aufsetzt und eine brauchbare Schnittstelle mitbringt.

Ein halbes Jahr später war es wieder draußen. Nicht, weil es schlecht ist, sondern weil es nicht zu meinem Aufbau passte.

Was gut funktioniert hat

Die Oberfläche. Für Leute, die Inhalte pflegen und keinen Editor öffnen wollen, ist so etwas Gold wert. Felder, Vorschau, Rollen, Freigabe-Ablauf — alles vorhanden, nichts selbst gebaut.

Die Bilderverwaltung. Hochladen, zuschneiden, in verschiedenen Größen ausliefern. Das ist eine Menge Arbeit, wenn man sie selbst macht.

Die automatische Schnittstelle. Jede Tabelle ist sofort über eine API erreichbar, mit Filtern und Sortierung. Für ein Frontend ist das bequem.

Woran es gescheitert ist

Ein weiterer Dienst im Betrieb. Wieder etwas, das laufen, aktualisiert, gesichert und überwacht werden muss. Bei einem System, das ohnehin aus mehreren Prozessen besteht, ist jeder zusätzliche Baustein spürbar.

Zwei Wahrheiten über dasselbe Schema. Das war der eigentliche Bruch. Meine Anwendungen beschreiben ihr Datenmodell in einer Schemadatei, aus der Struktur und Zugriffscode entstehen. Directus verwaltet sein eigenes Verständnis derselben Tabellen in eigenen Metatabellen. Wenn ich ein Feld ändere, muss beides nachgezogen werden — und wenn es auseinanderläuft, sieht man es erst, wenn etwas nicht funktioniert.

Rechte an zwei Stellen. Meine Anwendung hat ein Rechtesystem. Directus hat eins. Beide beschreiben, wer was darf, mit unterschiedlichen Begriffen. Bei jeder Änderung stellt sich die Frage, welches gilt.

Der Nutzen war klein. Am Ende habe ich damit Ankündigungen und ein paar Textbausteine gepflegt. Für diesen Umfang war der Aufwand nicht gerechtfertigt.

Wie ich es ersetzt habe

Mit zwei Dingen, die zusammen einen Bruchteil des Aufwands haben.

Für Texte, die selten geändert werden: Dateien im Repository. Markdown mit Kopfdaten, versioniert, mit Änderungshistorie und ohne zusätzlichen Dienst. Wer den Text ändert, macht eine Änderung im Projekt — das ist für mich als einzigen Autor völlig ausreichend.

Für Inhalte, die während des Betriebs entstehen: eigene Tabellen in der bestehenden Datenbank, mit einer schlichten Verwaltungsmaske in meinem eigenen Dashboard. Zehn Formularfelder statt eines Systems.

Interessant war, wie wenig davon tatsächlich nötig war. Von den sieben Sammlungen, die ich in Directus angelegt hatte, brauchte ich am Ende zwei.

Was der Umweg wert war

Ich schreibe das nicht als Warnung vor Directus, sondern als Beispiel für eine Entscheidung, die man erst im Betrieb bewerten kann.

Und der Umweg war nicht umsonst. Ich habe dabei drei Dinge gelernt, die ich seitdem selbst umsetze:

• Vorschau vor Veröffentlichung ist ein Feature, das man selbst fast nie einbaut und das Fehler verhindert.
• Bilder in mehreren Größen ausliefern sollte automatisch passieren, nicht beim Hochladen bedacht werden.
• Ein Entwurfszustand ist wertvoll. Etwas anlegen, ohne dass es sofort öffentlich ist, ist bei jedem Inhaltstyp sinnvoll — auch bei Blogeinträgen.

Diese drei Punkte stecken heute in meinen eigenen Verwaltungsmasken. Sie sind das, was von einem halben Jahr Umweg übrig geblieben ist, und ich hätte sie mir vermutlich nicht ausgedacht, ohne ein durchdachtes System benutzt zu haben.

Die Frage, die ich vorher hätte stellen sollen

Es gibt eine einzige Frage, die mir diesen Umweg erspart hätte: Wer pflegt hier Inhalte, und kann diese Person Code anfassen?

Bei zwei Antworten lohnt sich ein Redaktionssystem: „mehrere Leute" oder „jemand, der keinen Editor benutzt". Bei meiner Antwort — eine Person, die ohnehin den ganzen Tag im Editor sitzt — lohnt es sich nicht.

Diese Frage ist bei fast jedem Werkzeug anwendbar. Ein Aufgabenverwaltungssystem für eine Person ist meistens eine Textdatei. Ein Freigabeprozess für eine Person ist ein Umweg. Ein Rechtesystem für eine Person ist Bürokratie.

Das klingt selbstverständlich und ist es beim Einsetzen von Software überhaupt nicht — weil man sich an Beispielen orientiert, die aus Teams stammen.

Was ich beim Ausbau gelernt habe

Ein System wieder zu entfernen ist aufwendiger als es einzuführen, und der Grund liegt in den Daten.

Beim Einführen legt man ein System daneben und füllt es. Beim Entfernen muss man alles herausholen, in ein anderes Format bringen und sicherstellen, dass nichts verlorengeht — während die Anwendung weiterläuft und weiterhin Inhalte braucht.

Was mir dabei geholfen hat:

Erst exportieren, dann umstellen, dann abschalten. Nicht andersherum. Der Export lag als Dateisammlung vor, bevor ich eine Zeile geändert habe.

Die Adressen beibehalten. Ein Inhalt, der vorher unter einer bestimmten Adresse erreichbar war, sollte es danach auch sein. Sonst laufen Verweise ins Leere, die man nicht alle kennt.

Das alte System noch eine Weile laufen lassen, ohne dass es benutzt wird. Es kostet fast nichts und beantwortet die Frage „habe ich alles?" mit Sicherheit statt mit Hoffnung.

Was ich mir für die nächste Werkzeugentscheidung notiert habe

Aus diesem Umweg ist eine kurze Prüfliste geworden, die ich bei jedem fertigen System durchgehe, bevor ich es einsetze.

Wie viele Leute benutzen es, und können sie Code anfassen? Die Frage, die mir diesen Umweg erspart hätte.

Welches Modell hat es von meinen Daten, und passt es zu meinem? Zwei Beschreibungen derselben Struktur sind die teuerste Form von Doppelung.

Was passiert, wenn ich es wieder loswerden will? Bei Directus war der Export unproblematisch. Bei Systemen, die Daten in eigenen Formaten halten, ist diese Frage entscheidend — und sie stellt sich nur am Anfang gut.

Was von dem, was es kann, brauche ich tatsächlich? Bei mir waren es zwei von sieben Bereichen.

Die letzte Frage ist die, die man am ehesten übergeht, weil ein umfangreiches Werkzeug nach Zukunftssicherheit aussieht. Tatsächlich ist der ungenutzte Teil kein Vorrat, sondern Ballast: Er muss aktualisiert, verstanden und beim Umzug mitgenommen werden.

Die allgemeine Lehre

Fertige Systeme lohnen sich, wenn sie ein Problem lösen, das man tatsächlich hat, und wenn ihr Modell zu dem passt, was man ohnehin macht. Directus wäre für ein Redaktionsteam die richtige Wahl gewesen. Für einen Entwickler, der gelegentlich einen Text ändert, ist es eine zweite Wahrheit über dieselben Daten — und zwei Wahrheiten sind langfristig immer teurer als etwas mehr eigener Code.