Die Herausforderung
Was wir geliefert haben
Ein Backend für ein ganzes Netz von Apps
Bei zwei Apps kann man die Inhalte in Dateien innerhalb jeder App halten. Bei vierundzwanzig wird jede Korrektur an einer Textzeile zu einem neuen Release bei Google Play und einer Woche Wartezeit.
Wir haben eine Plattform gebaut, in der die Inhalte getrennt von den Apps leben: eine Redakteurin ändert sie im Backend, und die Telefone holen sich das aktualisierte Paket selbst — ohne die App zu aktualisieren.
Jede Kachel ist eine App: wie viele Einträge sie hält und welche Inhaltsversion gerade veröffentlicht ist.
Die App liest nur
Die zentrale Architekturentscheidung ist einfach: das Telefon schreibt nichts in die Plattform außer anonymen Ereignissen. Es holt das Manifest, holt das Paket der Einträge in seiner Sprache, und das war es. Keine Konten, keine Synchronisierung, keine Konflikte.
Deshalb entsteht eine neue App fast ohne Code: im Backend einen Eintrag anlegen, ein Schlüssel wird erzeugt, Kategorien und Einträge füllen, auf Veröffentlichen drücken — und die Inhaltsversion steigt um eins. Schlüssel und Adresse kommen in die App, danach läuft sie von selbst.
Vierundzwanzig Apps in einer Tabelle
Jede hat ihren Zugriffsschlüssel, ihren Satz an Sprachen, ihre Inhaltsversion und ihren Zustand. Man sieht, was veröffentlicht ist, was in Arbeit steckt und was noch eine Idee ist. Das ist keine Schauwand, sondern die Arbeitsliste, aus der das ganze Netz geführt wird.
Einträge verschiedener Form
Ein Rezept, eine Anleitung, eine Quizfrage, eine Spielkarte, ein Fehlercode, ein Rätsel, eine Tatsache — jedes Format hat sein eigenes Bearbeitungsformular, nicht ein einziges Feld namens „Text“. Hundert Einträge lassen sich per Import ergänzen: ein Array einfügen, Typ und Sprache wählen, und das System meldet Zeile für Zeile, was angenommen wurde, was nicht und warum.
Nicht bezahlen für das, was gleich geblieben ist
Das Paket einer App umfasst Hunderte Kilobyte. Es bei jedem Start herunterzuladen ergibt keinen Sinn, deshalb trägt die Antwort eine Versionsmarke: hat das Telefon bereits das aktuelle Paket, antwortet der Server „nichts geändert“ und sendet nichts.
Hier lag die Falle, die die Ersparnis lautlos zunichtemachte: ein Proxy, der Antworten komprimiert, schreibt die Marke in ihre „schwache“ Form um, und der strenge Vergleich passt nicht mehr. Das Telefon lud jedes Mal alles neu. Dem Vergleich musste beigebracht werden, alle drei Formen der Marke zu akzeptieren — die strenge, die schwache und die kommagetrennte.
Medien, die die App nicht aufblähen
Jedes Bild wird beim Hochladen nach WebP umgewandelt und in zwei Größen gehalten: vollständig bis 1200 Pixel und ein Vorschaubild bis 400. Der Server liefert sie mit langem Cache aus, und die App erhält fertige Adressen — keine Umwandlung auf dem Telefon.
Statistik ohne personenbezogene Daten
Die Apps senden anonyme Ereignisse — ein Öffnen, ein Wechsel, eine Aktion. Keine Kennungen einer Person, keine Kontakte. Höchstens fünfzig Ereignisse je Anfrage, und fehlerhafte Zeilen werden schlicht verworfen, statt den ganzen Aufruf scheitern zu lassen.
Daneben führt die Plattform die Zahlen aus dem App-Store und dem Werbenetz zusammen — damit Installationen und Erlöse dort gelesen werden, wo auch die Inhalte liegen, und nicht in drei verschiedenen Konsolen.
Projektablauf
Unter der Haube
Plattform
Laravel mit einem Filament-Backend. Es lebt auf gewöhnlichem Hosting: ohne Root, ohne Container, Warteschlange und Cache in der Datenbank, Bilder werden beim Hochladen umgewandelt.
API
Vier Lesepunkte, ein Schlüssel im Header, Grenzen je Schlüssel und je Adresse, eine Versionsmarke mit der Antwort „nichts geändert“. Fehler sind schlichtes JSON mit einem Code.
Ablage
Ein eigener Ort für Builds und Store-Material: Symbole, Bildschirmfotos, Beschreibungen. Dazu Querverweise zwischen den Apps des Netzes.
Das Ergebnis
Ein Netz aus vierundzwanzig Apps, in dem eine Textkorrektur den Nutzer in Minuten erreicht statt in einer Woche. Eine neue App entsteht im Backend in wenigen Minuten: anlegen, füllen, veröffentlichen, Schlüssel einsetzen.
Und das alles läuft auf gewöhnlichem Hosting — ohne eigenen Server, ohne Warteschlangen im Arbeitsspeicher und ohne Container, für die es dort ohnehin keinen Platz gäbe.
