Wenn zwei Programme miteinander reden, fällt ein Fehler oft nirgends auf. Bei mir schickte eine App neun Tage lang Kundendaten an eine Adresse auf meinem eigenen Server, die es nicht mehr gab. Angekommen ist nichts, aber keine Seite schlug Alarm. Passiert ist das beim Bau meiner zweiten Webapp: macher.one, gebaut für meine Projekte und Kunden, auf einem eigenen Server und bewusst getrennt von KIRA.
Für dich in 30 Sekunden
- Trenne, was für dich ist, von dem, was Kunden sehen. Zwei getrennte Welten sind leichter abzusichern als eine gemischte.
- Ein Ausfall muss sich melden. „Null offene Rechnungen“ wirkt beruhigend, auch wenn in Wahrheit die Verbindung tot ist.
- Baust du etwas um, prüf auch alles, was darauf zugreift. Fehler entstehen selten dort, wo man gerade arbeitet.
Lesezeit rund 7 Minuten
Was ich wollte: einen eigenen Ort für Projekte und Kunden
Seit Januar hatte ich eine kleine Projekt-App: Kunden, Aufgaben, später Rechnungen. Sie war für mich gebaut, als mein Arbeitsplatz. Meine Kunden sollten aber einen eigenen Zugang bekommen, mit ihren Projekten und dem, was ich für sie mache. In meine Projekt-App wollte ich dafür niemanden lassen.
Der Name war älter als die Webapp. macher.one war schon immer für die Entwicklung von Plugins für WordPress und WooCommerce gedacht, und die Adresse passte genau: dermacher.at bietet das Fundament, macher.one die Umsetzung mit KI.
In meinen Unterlagen taucht macher.one am 14. März zum ersten Mal auf, in einer Notiz im Änderungsprotokoll der Projekt-App: Eine bestimmte Regel soll in macher.one „von Anfang an eingebaut“ werden. Am Tag danach stand der Server.
Was ich gemacht habe: eine Webapp für Projekte und Kunden
Am 15. März: ein eigener Server
KIRA läuft auf demselben Server wie meine Website, einem gewöhnlichen Webspace. Für macher.one habe ich einen eigenen Server bei Hetzner gemietet. Ein Server ist ein Rechner in einem Rechenzentrum, der rund um die Uhr läuft. Bei einem gemieteten Server richte ich alles selbst ein: Betriebssystem, Webserver, Datenbank, Verschlüsselung. Genau das steht im Änderungsprotokoll bei der allerersten Version vom 15. März.
Der Grund für den eigenen Server war die Trennung. KIRA und macher.one hängen in manchen Dingen zusammen, aber sie sollen einander nicht mitreißen. Ist der eine Bereich nicht erreichbar, soll der andere weiter funktionieren.
Zwei Wochen reines PHP, dann Laravel
Die ersten zwei Wochen war macher.one in reinem PHP geschrieben, so wie KIRA auch. Am 28. März habe ich das Konzept dazu aufgeschrieben, und darin steht eine Überschrift, die bis heute gilt: „Zwei Welten, klar getrennt“. Meine Projekt-App bleibt meine, die Webapp ist für die Kunden. Wörtlich: „Der Kunde sieht projekte.dermacher.at nie.“
Die Projekt-App selbst gibt es heute nicht mehr. Nach und nach hat macher.one ihre Aufgaben übernommen, am 24. Juli wurde sie abgeschaltet.
Am 30. März kamen Anmeldung, Dashboard und eine Sperr-Seite dazu. Die Kundendaten wanderten per Klick auf einen Button aus der Projekt-App hinüber. Und am 31. März fiel die Entscheidung für Laravel.
Laravel ist ein Framework, also ein Baukasten für Webanwendungen. Vieles, was man sonst selbst schreibt, liegt dort fertig und erprobt bereit: die Anmeldung, der Zugriff auf die Datenbank, die Adressen der Seiten, Tests. Im Plan von damals steht der Grund in einem Satz: „Radikal einfach, aber mit solidem Framework-Fundament.“ Daneben eine Tabelle, was Laravel uns abnimmt, darunter zwei Zeilen: eine fertige, sichere Anmeldung statt einer selbst gebauten, und Tests ab dem ersten Tag statt gar keiner.
Laravel und der eigene Server bei Hetzner waren meine Idee. Ich habe Claude aber gefragt, ob das überhaupt möglich ist, ob es Sinn macht, oder ob eine andere Variante besser wäre.
An einem einzigen Tag wurde die ganze App umgestellt. Laut Änderungsprotokoll blieben alle bisherigen Funktionen erhalten.
Getrennt, aber nicht unabhängig
Ganz ohne einander kommen die beiden nicht aus. KIRA holt sich zum Beispiel meine Aufgaben aus macher.one, und macher.one bekommt von KIRA, was es für die KI-Texte braucht. Jede dieser Verbindungen hat eine Zeitgrenze: Antwortet die andere Seite nicht innerhalb weniger Sekunden, wird nicht weiter gewartet. Was dann passiert, habe ich mir für dieses Kapitel im heutigen Code angesehen:
Die Trennung hält also: Keine Seite bringt die andere zum Stillstand. Aber es fehlen Teile, und nicht jede Lücke meldet sich.
Was schwierig war: eine Verbindung, die ins Leere lief
Die Umstellung auf Laravel hatte eine Nebenwirkung, die niemand bemerkt hat. Die Projekt-App schickte ihre Kundendaten weiterhin an die alte Adresse, die es nach der Umstellung nicht mehr gab. Jeder Versuch endete mit einem Fehler, und zwar vom 31. März bis zum 9. April. Neun Tage lang ist nichts angekommen, und keine der beiden Seiten hat Alarm geschlagen. Repariert wurde es am 9. April.
Die zweite Überraschung kam am 3. April: Die Firewall meines Webspaces hat den neuen Server ausgesperrt. Eine strenge Firewall lässt einen fremden Server erst durch, wenn er ausdrücklich freigeschaltet ist. Das ging beim Hoster, aber man muss erst einmal darauf kommen.
Beides hat dieselbe Ursache: Geändert wurde eine Seite, und die andere Seite, die sie aufruft, wurde nicht mitgeprüft. Heute steht in KIRAs Checkliste für jede Code-Änderung eine eigene Zeile dafür: Wird eine Schnittstelle geändert, werden zuerst alle gesucht, die sie aufrufen.
Merksatz:
Wer umbaut, prüft auch alle, die anklopfen.
Was du daraus mitnehmen kannst: Tipps für deine eigene Webapp
- Trenne, was für dich ist, von dem, was Kunden sehen. Zwei Welten sind einfacher abzusichern als eine gemischte.
- Gib getrennten Aufgaben getrennte Server, wenn ein Ausfall nicht alles mitreißen soll. Dann bleibt der eine Bereich nutzbar, wenn der andere hängt.
- Gib jeder Verbindung eine Zeitgrenze und einen Plan für den Ausfall. Und sorg dafür, dass ein Ausfall gemeldet wird, statt als leere Liste auszusehen.
- Nimm einen Baukasten, wo es ihn gibt. Anmeldung und Datenbankzugriff selbst zu bauen ist Arbeit, die sich andere schon gemacht haben.
- Prüf nach jeder Umstellung alle, die das Umgestellte aufrufen. Die Fehler entstehen selten dort, wo man gerade arbeitet.
Ohne selbst zu programmieren
Die stille Null kennst du vielleicht aus deinen eigenen Werkzeugen: ein Bericht ohne Einträge, ein Abgleich ohne Meldung, ein Postfach, aus dem seit Tagen nichts mehr kommt. Frag dich bei jedem Bericht, auf den du dich verlässt: Woran würde ich merken, dass er gar nicht mehr läuft? Und stellst du ein Werkzeug um, etwa Kalender, Buchhaltung oder Onlineshop, dann schreib vorher auf, was alles daran hängt, und prüf jedes davon danach einmal von Hand.
Fragen, die du der KI stellen kannst
- „Was ist der Unterschied zwischen Webspace und einem eigenen Server, und was brauche ich für eine kleine Webapp mit Anmeldung?“
- „Welche Teile meiner App müsste ich selbst bauen, und welche bringt ein Framework fertig mit?“
- „Zeig mir jede Stelle in meinem Projekt, an der es einen anderen Server aufruft, mit Datei und Zeile, mit der Zeitgrenze und mit dem, was bei einem Ausfall passiert.“
Wie es weitergeht: ein Plugin auf jeder Kundenseite
Eine Webapp für Kunden nützt wenig, wenn sie nicht weiß, wie es den Websites der Kunden geht. Schon am 26. März war dafür ein eigenes Plugin fertig, das jeden Morgen meldet, welche Updates bei WordPress, Plugins und Theme offen sind. Nur eine Sorte Updates sah es nicht, ausgerechnet die von gekauften Plugins. Warum, und was dagegen half, erzähle ich in Kapitel 12.
Was du noch wissen solltest
PHP ist eine Programmiersprache, die auf dem Server läuft und dort die Seiten zusammenbaut, bevor sie an den Browser gehen. WordPress ist zum Beispiel in PHP geschrieben, deshalb kann fast jeder Webspace damit umgehen. Reines PHP heißt: ohne Framework, alles selbst geschrieben.
Beim Webspace teilst du dir einen Server mit anderen Kunden, der Anbieter kümmert sich um Technik, Updates und Sicherheit, dafür sind die Möglichkeiten begrenzt. Beim eigenen, gemieteten Server hast du volle Kontrolle und kannst einrichten, was du willst. Der Preis dafür ist Aufwand: Sicherheitsupdates, Sicherungen und Überwachung sind dann deine Aufgabe.
Eine Firewall ist ein Türsteher für einen Server: Sie lässt nur Verbindungen durch, die erlaubt sind, und blockt verdächtige. Hoster setzen sie ein, um Angriffe abzuwehren. Ein unbekannter Server, der plötzlich regelmäßig anfragt, kann dabei wie ein Angreifer aussehen und bleibt gesperrt, bis man ihn ausdrücklich freischaltet.
Die Zeitgrenze, nach der ein Programm aufhört, auf eine Antwort zu warten. Ohne sie würde eine Seite, die eine nicht erreichbare Gegenstelle fragt, selbst hängen bleiben, und der Ausfall der einen Seite würde die andere mitreißen. Wichtig ist, was nach dem Timeout passiert: Eine sichtbare Meldung ist besser als ein stiller Ersatzwert wie null.
Nur, wenn man es vorher eingebaut hat. Üblich ist, jeden fehlgeschlagenen Aufruf zu protokollieren und bei wiederholten Fehlern eine Meldung zu schicken, etwa per Mail. Noch einfacher ist ein regelmäßiger Testaufruf, der Alarm schlägt, wenn keine Antwort kommt. Ohne so etwas fällt ein Ausfall oft erst auf, wenn Daten fehlen.
