Zum Inhalt
quentin/bastos
← Zurück zur Startseite

Persönliches Projekt, allein umgesetzt · 2025

SparkleQuiz

Quiz-App für Einzel- und Mehrspieler, in Produktion im Web, auf Android und iOS.

Visual von SparkleQuiz
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.

Web
Android
iOS

Vue 3 + TypeScript · Capacitor

Caddy · blue / green
API Symfony 7 · PHP 8.2
MariaDB
Daten
Redis
Cache, Warteschlangen
Mercure
Echtzeit
Per GitHub Actions auf einen VPS deployt, bei jedem Tag in den Stores veröffentlicht.

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.