Zum Inhalt springen
TAA
Notiz 3 Min. Lesezeit

App-Architektur im Alltag: wenn ein Commit die ganze Woche ist

Ein Commit, frische Daten für eine Website und die ehrlichste Frage, die sich ein Ein-Mann-Betrieb stellen kann: Was zählt als Arbeitswoche?

  • app architektur
  • build-in-public
  • astro
  • statische-website
  • wartung
Teilen

Ein automatischer Job hätte das auch erledigen können, aber ich habe es von Hand gemacht: die zwischengespeicherten Daten einer kleinen statischen Website aktualisiert, gepusht, fertig. Ein Commit. Danach kam nichts mehr, keine weiteren Commits in dieser Woche, kein neues Feature, kein Release und kein Umbau. Nur dieser eine kleine Handgriff an einer laufenden Website. So war die Woche.

Ich schreibe trotzdem darüber. Nicht, um sie größer zu machen, als sie war, sondern weil genau darin der Punkt liegt.

App-Architektur heißt auch, Dinge einfach laufen zu lassen

Die Website ist eine Astro-Site, die ich gebaut habe. Sie ist live und funktioniert. Ungefähr einmal pro Woche schaue ich nach, ob irgendwo etwas hakt. Diesmal waren die Daten veraltet. Der Build holt beim Kompilieren externe Feed-Daten aus einer API, und diese Daten lagen einige Wochen zurück. Also habe ich das Abrufskript laufen lassen, die Daten geprüft, committet und deployt.

Das klingt banal, und das ist es auch. Trotzdem steckt dahinter eine bewusste Entscheidung beim Aufbau der Website. Ich lade die Daten nicht live im Browser, weil das eine API-Abhängigkeit im Client schafft, die ich nicht kontrolliere. Stattdessen backe ich die Daten beim Build ein. So bleibt die Website schnell und unabhängig vom Kontingent der API, und der Besucher sieht keine halb geladene Seite, wenn die API einmal langsam antwortet. Der Preis: Ich muss gelegentlich neu deployen, wenn die Daten zu alt werden. Ein fairer Tausch.

Ehrlich gesagt bin ich noch unentschieden, ob das auf Dauer die richtige Lösung ist. Ein Rebuild per Webhook, ausgelöst, sobald sich an der Quelle etwas ändert, wäre eleganter. Dann würden sich die Daten von selbst aktualisieren, ohne dass ich den Abruf von Hand anstoße. Diesen Umbau habe ich in Gedanken schon dreimal begonnen und nie zu Ende geplant. Irgendwann.

Was eine stille Woche über Wartung verrät

Ich lasse diese Woche so stehen, wie sie war. Das halte ich für ehrlich, und es zeigt etwas, das bei öffentlichen Arbeitsberichten selten ausgesprochen wird: Die meiste Zeit, die in eine laufende App oder Website fließt, ist unsichtbar. Sie taucht in keinem Changelog auf und erzeugt keinen Pull Request. Arbeit ist es trotzdem.

Wenn Sie überlegen, eine App entwickeln zu lassen, übersehen Sie beim Vergleich von Angeboten leicht genau diesen Teil. Was passiert nach dem Start? Wer hält die App am Laufen? Wer bemerkt, dass die Daten drei Wochen alt sind, und behebt das, bevor es jemand anderem auffällt?

Das ist keine spektakuläre Fähigkeit. Sie entscheidet aber darüber, ob eine App nach einem Jahr noch gepflegt wirkt oder langsam verstaubt.

Nächste Woche steht mehr an. Ich möchte die Datenaktualisierung endlich automatisieren und habe in einem anderen Repository noch ein offenes Thema, das ich diese Woche bewusst liegen gelassen habe. Mehr dazu, sobald es fertig ist.

Was ich für Kunden baue und wie meine Arbeit aufgebaut ist, steht in der Leistungsübersicht.

Teilen