Persönliches Projekt, allein umgesetzt · 2025
SparkleQuiz
Quiz-App für Einzel- und Mehrspieler, in Produktion im Web, auf Android und iOS.
- Plattformen: Web, Android, iOS
- 3
- veröffentlichte Versionen
- 210+
- PHPUnit-Tests
- ~6 000
- Ausfallzeit pro Deployment
- 0
Allein konzipiert, entwickelt und betrieben: Symfony-API, Vue-3-Front-End, mobile Apps mit Capacitor, Echtzeit-Partien, Ranglisten und von Spielern erstellte Quiz.
Meine Rolle. Einziger Entwickler: Konzeption, Back-End, Front-End, mobile Apps, Infrastruktur und Store-Veröffentlichungen.
Was ich gemacht habe
- Komplettes Fortschrittssystem: Level, Erfahrungspunkte, tägliche Aufgaben, 68 Trophäen und 4 mit Game Center synchronisierte Ranglisten.
- Acht GitHub-Actions-Pipelines: Tests, Docker-Deployments in Produktion, Store-Veröffentlichung, Aktualisierung der Store-Einträge.
- End-to-End-Tests mit Playwright im Web und Maestro auf Mobile, Lighthouse-Audits.
Ausgangspunkt
Ich wollte ein Projekt, das mich zwingt, alles zu tun, was ein Unternehmen tut, ohne Sicherheitsnetz: Produkt, Architektur, Datenbank, Front-End, mobile Apps, und das Ganze dann in Produktion betreiben und am Leben halten.
Architektur
Eine Symfony-7-API auf MariaDB bedient die Website und die Apps. Das Front-End in Vue 3 und TypeScript ist überall derselbe Code: Capacitor verpackt es für Android und iOS. Redis übernimmt Cache und Nachrichtenwarteschlange, Mercure verteilt die Echtzeit-Ereignisse.
Eine bewusste Entscheidung: ein gut strukturierter Monolith statt Microservices. Für ein Ein-Personen-Team lässt er sich am schnellsten ausliefern, testen und debuggen.
Vue 3 + TypeScript · Capacitor
Echtzeit
Mehrspieler-Partien laufen über Mercure (Server-Sent Events) statt über eigene WebSockets: weniger Servercode, die Wiederverbindung übernimmt der Browser, und die Berechtigungen der Kanäle bleiben in Symfony.
Qualität und CI
Jede Änderung durchläuft dieselbe Prüfung: PHPStan, PHP-CS-Fixer, PHPUnit, Lint und Typprüfung im Front-End, Vitest, Vollständigkeit der Übersetzungen und ein CSS-Budget. Playwright spielt jede Nacht die kritischen Abläufe durch.
In der API gilt eine einfache Regel: Jeder vorhersehbare Fehler liefert ein klares 4xx, ein 5xx bedeutet einen echten Bug und landet im Monitoring.
Deployment
Ein Push auf main deployt die Website über GitHub Actions auf meinen Server, Blue/Green hinter Caddy: Die neue Version startet neben der alten und übernimmt den Verkehr erst, wenn sie gesund ist. Ein Versions-Tag veröffentlicht die App bei Google Play und reicht sie bei Apple ein. Dringende Korrekturen gehen als Live-Update raus, ohne Umweg über die Stores.
Was ich dabei gelernt habe
Schwierig ist nicht, die Funktion zu schreiben, sondern sie in Produktion stabil zu halten: Migrationen ohne Ausfallzeit, Kompatibilität mit älteren, noch installierten App-Versionen, Leistung auf einfachen Smartphones und Tests, die zuverlässig genug sind, um oft und ohne Angst auszuliefern.