HERRAMIENTA COMUNITARIA · 2025 – ACTUALIDAD
KillReport
Una plataforma en tiempo real para seguir y analizar killmails de jugadores, corporaciones y alianzas en EVE Online. Se sincroniza con zKillboard y con la API oficial de EVE (ESI) y, según las condiciones de licencia de CCP, no es comercial.
Mi función: El diseño, el desarrollo y la operación son completamente míos.
- workers en segundo plano
- ~45
- modelos de datos
- 42
- límite de API compartido
- 50 req/s
- suscripciones GraphQL
- En vivo
El problema
Cada combate del juego genera un registro de killmail, y esos registros no dejan de llegar. Para enriquecer cada registro hacen falta muchas peticiones a una API externa, y esa API tiene un límite de peticiones estricto.
Las clasificaciones y el feed en vivo deben mantenerse al día sin retraso; si un worker falla o se reinicia, la web no puede quedarse parada.
Arquitectura
Fuentes de datos
zKillboard · ESI
Cola de tareas
- RabbitMQ
Reparto de tareas
Workers
- TypeScript
~45 procesos
Capa de datos
- PostgreSQL
- Prisma
- Redis
Datos persistentes y eventos
API
- GraphQL Yoga
Suscripciones en vivo
Frontend
- Next.js
App Router
El servidor de la API y los workers son procesos separados que solo se comunican a través de Redis; por eso pueden reiniciarse de forma independiente.
Lo que he construido
Feed en vivo
Los nuevos killmails aparecen al instante en la página mediante suscripciones GraphQL.
Personajes, corporaciones, alianzas
Historial, estadísticas y sincronización automática para cada entidad.
Clasificaciones
Los contadores diarios se actualizan en la misma transacción que el registro; no hace falta una tarea programada aparte.
Soberanía y mapa
Seguimiento de regiones, sistemas estelares y campañas de soberanía.
Panel de workers
Una pantalla de monitorización que muestra el estado de las colas y los workers.
EVE SSO
Los jugadores inician sesión con su propia cuenta de EVE; los tokens se renuevan automáticamente.
Problemas difíciles que he resuelto
- 1
Un límite de peticiones compartido entre procesos
ESI permite 150 peticiones por segundo. Como decenas de workers comparten el mismo límite, escribí un limitador compartido basado en Redis y lo fijé en 50 peticiones por segundo como margen de seguridad.
- 2
Clasificaciones al día sin tareas programadas
Los contadores diarios se incrementan de forma atómica en la misma transacción de base de datos que guarda el killmail. Las clasificaciones nunca están desfasadas y no hace falta un cron aparte.
- 3
Proteger tablas fuera del esquema
Añadí una protección que evita que las migraciones del ORM eliminen tablas escritas a mano por rendimiento.
Tecnologías
- Next.js
- React
- TypeScript
- GraphQL
- Prisma
- PostgreSQL
- Redis
- RabbitMQ
- GitHub Actions
Servicios relacionados
¿Está construyendo un sistema similar? Podemos trabajar juntos desde la arquitectura hasta la puesta en producción.
Contactar