Der Blog zieht von MDX-Dateien in die Datenbank

Seit dem Aufbau meiner Seite lagen die Blogbeiträge als Dateien im Projekt: eine .mdx pro Beitrag, mit Kopfdaten und Text, verarbeitet beim Bauen. Das ist ein schöner Aufbau, und ich habe ihn zwei Jahre lang verteidigt.

Heute liegen die Beiträge in der Datenbank.

Warum Dateien so lange gut waren

Versionsverwaltung ohne Zusatzaufwand. Jede Änderung ist ein Commit. Man sieht, was wann geändert wurde, und kann zurück.

Kein zusätzliches System. Keine Tabelle, keine Maske, kein Anmelden.

Der Text gehört einem. Eine Markdown-Datei ist in zehn Jahren noch lesbar, unabhängig davon, was mit meiner Anwendung passiert.

Schreiben im Editor. Für jemanden, der ohnehin den ganzen Tag in einem sitzt, der kürzeste Weg.

Diese vier Punkte gelten weiterhin. Es sind gute Argumente, und wer sie hat und keinen Gegengrund, sollte bei Dateien bleiben.

Was mich zum Wechsel gebracht hat

Ich konnte nur dort schreiben, wo das Repository liegt. Ein Tippfehler auf dem Handy: nicht korrigierbar. Ein Gedanke unterwegs: nicht festhaltbar. Das ist die Sorte kleine Hürde, die dazu führt, dass man Dinge nicht macht.

Jede Änderung brauchte einen neuen Bau. Beiträge wurden beim Bauen verarbeitet, also erschien ein neuer Text erst nach einem vollständigen Durchlauf. Bei einem Bau, der Minuten dauert, ist eine Korrektur eines einzelnen Wortes ein größerer Vorgang.

Der Wiki-Bereich lag bereits in der Datenbank. Und damit hatte ich zwei verschiedene Wege für zwei sehr ähnliche Dinge — mit zwei Editoren, zwei Vorschauen, zwei Vorstellungen von Entwürfen. Diese Uneinheitlichkeit war der eigentliche Auslöser.

Was gleich bleiben musste

Beim Umzug war mir eines wichtig: Der Inhalt bleibt MDX. Nicht HTML, nicht ein proprietäres Format aus einem Editor.

Der Grund ist derselbe wie beim Punkt „der Text gehört einem": Ein Datenbankfeld mit MDX ist genauso portabel wie eine Datei mit MDX. Ich kann jederzeit alles exportieren und habe wieder einen Ordner mit Dateien.

CREATE TABLE blog_posts (
  id            TEXT PRIMARY KEY,
  slug          TEXT UNIQUE NOT NULL,
  title         TEXT NOT NULL,
  summary       TEXT,
  body_mdx      TEXT NOT NULL,
  tags          TEXT NOT NULL DEFAULT '[]',
  headings      TEXT NOT NULL DEFAULT '[]',
  reading_time  TEXT NOT NULL DEFAULT '{}',
  word_count    INTEGER,
  is_draft      INTEGER NOT NULL DEFAULT 0,
  published_at  TEXT,
  created_at    TEXT NOT NULL,
  updated_at    TEXT NOT NULL
);

Die berechneten Felder — Überschriften, Lesezeit, Wortzahl — werden beim Speichern erzeugt und mitgeschrieben. Das ist bewusst Redundanz: Sie ließen sich jederzeit aus dem Text ableiten, aber dann müsste das bei jedem Aufruf passieren. Wichtig ist nur, dass sie an genau einer Stelle entstehen.

Was ich mir eingehandelt habe

Die Versionshistorie musste ich selbst bauen. Bei Dateien schenkt einem die Versionsverwaltung das. Ich habe deshalb eine Fassungstabelle angelegt: Bei jedem Speichern wird der vorherige Stand mit einer laufenden Nummer abgelegt.

Die Sicherung ist jetzt relevanter. Solange die Texte im Repository lagen, existierten sie auf jedem Rechner, auf dem ich gearbeitet habe. Jetzt liegen sie in einer Datenbankdatei — und wenn die weg ist, sind sie weg. Ein regelmäßiger Export in ein Verzeichnis ist deshalb Teil des Sicherungsplans.

Ein Fehler im Text kann eine Seite kaputtmachen. MDX wird bei mir zur Laufzeit verarbeitet. Ein Syntaxfehler ist damit kein Baufehler mehr, den man vor der Veröffentlichung sieht, sondern eine Fehlerseite. Also braucht es eine Prüfung beim Speichern — Text testweise verarbeiten, und nur speichern, wenn es durchläuft.

Der Umzug selbst

Ein Skript, das den Ordner durchgeht, die Kopfdaten liest, die berechneten Felder erzeugt und Datensätze anlegt. Fünf Beiträge, zwei Minuten.

Danach ein Vergleich: Wird jeder Beitrag unter derselben Adresse gefunden wie vorher? Das ist der Punkt, an dem man vorsichtig sein muss — eine geänderte Adressbildung bedeutet, dass jeder bestehende Verweis von außen ins Leere läuft.

Die Dateien habe ich nicht gelöscht. Sie liegen weiterhin im Repository, als Ausgangsstand und als Beleg dafür, dass ein Export tatsächlich dasselbe ergibt.

Der Export, der das Ganze absichert

Die wichtigste Eigenschaft dieses Umzugs ist eine, die man nicht sieht: Er ist umkehrbar.

Es gibt ein Skript, das jeden Beitrag aus der Datenbank als Datei mit Kopfdaten schreibt — genau in dem Format, in dem sie vorher lagen. Es läuft regelmäßig, und das Ergebnis liegt versioniert im Projekt.

Damit sind drei Dinge auf einmal gelöst:

Eine zusätzliche Sicherung, unabhängig von der Datenbanksicherung und in einem Format, das man ohne Werkzeuge lesen kann.

Der Rückweg. Wenn ich in zwei Jahren feststelle, dass die Datenbank die falsche Wahl war, ist der Weg zurück ein Kopiervorgang.

Die Unabhängigkeit vom System. Meine Texte gehören nicht meiner Anwendung. Sie liegen als Markdown vor, und das ist in zehn Jahren noch lesbar.

Diesen Export habe ich am selben Tag gebaut wie den Import — bewusst, weil er sonst nie entstanden wäre. Ein Rückweg, den man „später mal baut", ist keiner.

Was ich beim Schreiben in der Oberfläche gemerkt habe

Der eigentliche Zweck des Umzugs war, überall schreiben zu können. Nach ein paar Wochen konnte ich einschätzen, ob sich das gelohnt hat.

Ja — aber anders als gedacht. Ich schreibe kaum längere Texte am Handy. Was ich mache: Tippfehler korrigieren, einen Absatz ergänzen, der mir unterwegs eingefallen ist, einen Entwurf anlegen mit drei Stichpunkten.

Das sind alles kleine Sachen, und sie waren vorher schlicht unmöglich. Eine Korrektur, die eine Entwicklungsumgebung, ein Repository und einen Bau verlangt, wird nicht gemacht — auch wenn sie zehn Sekunden Schreibarbeit ist.

Was ich daraus mitgenommen habe: Der Wert eines Werkzeugs zeigt sich in den kleinen Vorgängen, nicht in den großen. Für einen ganzen Beitrag ist der Editor am Rechner unschlagbar. Für die zwanzig Kleinigkeiten drumherum entscheidet, wie niedrig die Hürde ist.

Was ich rückblickend als Muster sehe

Der Wechsel hatte nichts mit Technik zu tun und alles mit Reibung. Dateien waren nicht schlechter — sie waren an einer Stelle unbequem, und diese Unbequemlichkeit hat mein Verhalten verändert. Ich habe weniger geschrieben, weil Schreiben an einen Ort gebunden war.

Das ist derselbe Grund, der beim Datenbankwechsel den Ausschlag gegeben hat: nicht Leistungsdaten, sondern ein Alltagsvorgang, der zu umständlich war. Ich glaube inzwischen, dass die meisten guten Umbauten diese Form haben.