COMMUNITY-TOOL · 2025 – HEUTE
KillReport
Eine Echtzeitplattform zur Erfassung und Analyse von Killmails für Spieler, Corporations und Allianzen in EVE Online. Sie synchronisiert sich mit zKillboard und der offiziellen EVE-API (ESI) und ist gemäß den Lizenzbedingungen von CCP nicht kommerziell.
Meine Rolle: Design, Entwicklung und Betrieb liegen vollständig bei mir.
killreport.com- Hintergrund-Worker
- ~45
- Datenmodelle
- 42
- gemeinsames API-Limit
- 50 req/s
- GraphQL-Subscriptions
- Live
Das Problem
Jeder Kampf im Spiel erzeugt einen Killmail-Datensatz, und diese Datensätze reißen nie ab. Jeder Datensatz braucht zur Anreicherung viele Anfragen an eine externe API, und diese API hat ein striktes Rate Limit.
Ranglisten und Live-Feed müssen ohne Verzögerung aktuell bleiben; stürzt ein Worker ab oder startet neu, darf die Website nicht ausfallen.
Architektur
Datenquellen
zKillboard · ESI
Job-Queue
- RabbitMQ
Aufgabenverteilung
Worker
- TypeScript
~45 Prozesse
Datenschicht
- PostgreSQL
- Prisma
- Redis
Persistenz und Ereignisse
API
- GraphQL Yoga
Live-Subscriptions
Frontend
- Next.js
App Router
API-Server und Worker sind getrennte Prozesse, die nur über Redis miteinander kommunizieren; so lässt sich jeder unabhängig neu starten.
Was ich umgesetzt habe
Live-Feed
Neue Killmails erscheinen über GraphQL-Subscriptions sofort auf der Seite.
Charaktere, Corporations, Allianzen
Verlauf, Statistiken und automatische Synchronisierung für jede Entität.
Ranglisten
Tageszähler werden in derselben Transaktion wie der Datensatz aktualisiert; ein separater geplanter Job ist nicht nötig.
Souveränität und Karte
Verfolgung von Regionen, Sonnensystemen und Souveränitätskampagnen.
Worker-Dashboard
Eine Monitoring-Ansicht, die den Zustand von Queues und Workern zeigt.
EVE SSO
Spieler melden sich mit ihrem eigenen EVE-Konto an; Tokens werden automatisch erneuert.
Schwierige Aufgaben, die ich gelöst habe
- 1
Ein Rate Limit über mehrere Prozesse hinweg
ESI erlaubt 150 Anfragen pro Sekunde. Da sich Dutzende Worker dasselbe Limit teilen, habe ich einen gemeinsamen Limiter auf Redis-Basis geschrieben und ihn mit Sicherheitsabstand auf 50 Anfragen pro Sekunde begrenzt.
- 2
Aktuelle Ranglisten ohne geplante Jobs
Tageszähler werden atomar in derselben Datenbanktransaktion erhöht, die den Killmail speichert. Die Ranglisten sind nie veraltet, und ein separater Cronjob ist nicht nötig.
- 3
Schutz von Tabellen außerhalb des Schemas
Ich habe eine Absicherung eingebaut, die verhindert, dass aus Performancegründen handgeschriebene Tabellen durch ORM-Migrationen gelöscht werden.
Technologien
- Next.js
- React
- TypeScript
- GraphQL
- Prisma
- PostgreSQL
- Redis
- RabbitMQ
- GitHub Actions
Passende Leistungen
Sie planen ein ähnliches System? Ich begleite Sie von der Architektur bis zum Go-live.
Kontakt aufnehmen