Proyecto
MatchTracker
Backend-first para seguir partidas de League of Legends, persistir actividad de jugadores y lanzar notificaciones automáticas cuando aparece una nueva partida.
- Java
- Spring Boot 4
- Spring WebFlux
- Spring MVC
- Thymeleaf
- PostgreSQL
- Docker
- Actuator
Contexto
De qué punto partíamos
Enfoque
Cómo lo trabajé
Construcción de un backend-first con panel operativo server-rendered, API interna, polling programado contra Riot, persistencia de jugadores y partidas, auditoría básica de ejecuciones y salida por Telegram para avisar de nuevas partidas.
Decisiones
Decisiones y compromisos relevantes
- Combinar Spring MVC para la parte operativa y WebFlux para las integraciones externas, manteniendo una sola aplicación pero aprovechando cada enfoque donde mejor encajaba.
- Persistir un modelo reducido de partidas y jugadores para centrarme en el valor del seguimiento y la deduplicación, en lugar de intentar replicar todo el payload de Riot.
- Registrar ejecuciones de polling, errores y resultados para que el proyecto tuviera un mínimo de observabilidad y no fuera una caja negra.
- Cubrir el flujo principal con tests de servicio e integración sin depender de Riot ni de Telegram en vivo, para poder iterar con seguridad.
Resultado
Qué cambió
- Aplicación funcional para gestionar jugadores, consultar partidas recientes y lanzar polling manual o programado desde un dashboard propio.
- Integración real con Riot y Telegram sobre una base mantenible, con persistencia de jugadores, partidas y ejecuciones.
- Proyecto muy útil para consolidar patrones reactivos, uso de WebClient, modelado de dominio simple y pruebas de flujo extremo a extremo.
Aprendizaje
Con qué me quedé
- Los proyectos personales son un buen laboratorio para probar tecnología nueva, pero solo de verdad cuando los llevas hasta un flujo usable y no se quedan en una demo.
- WebFlux me sirvió para entender mejor conceptos como event loop, backpressure e integraciones I/O-bound, incluso dentro de una aplicación que no pretendía ser 100 % reactiva.
- También me ayudó a afinar criterio sobre cuánto sofisticar una arquitectura y cuándo merece más la pena mantener un monolito pequeño, claro y fácil de operar.
Continuidad
Sigue explorando
Navega al caso anterior o siguiente, o salta a proyectos relacionados.
Más contexto
Lo que merece ampliar
MatchTracker nació como una mezcla deliberada entre hobby y laboratorio técnico. La idea era sencilla: seguir partidas recientes de League of Legends, guardar la información relevante y recibir avisos cuando hubiera actividad nueva. Lo interesante no era el dominio en sí, sino usarlo para construir una aplicación real con integraciones externas, persistencia, panel operativo y un flujo que mereciera mantenerse encendido.
Fue también una manera de obligarme a salir de la zona de confort. Quería tocar Spring Boot 4, trabajar con WebFlux y WebClient contra APIs públicas, recuperar soltura con PostgreSQL y pensar cómo diseñar una aplicación pequeña pero seria si tuviera que convivir con ella más tiempo del habitual. La idea de explorar Loom estuvo sobre la mesa al inicio, pero donde más aprendí fue en integraciones reactivas, polling y control del flujo alrededor de I/O.
El resultado es una aplicación backend-first que combina un panel server-rendered para operaciones, endpoints internos para jugadores y ejecuciones, polling programado contra Riot, deduplicación de partidas y notificaciones por Telegram cuando aparece algo nuevo. No es el típico side project de hola mundo con una API externa: aquí me interesaba cerrar el círculo completo, desde la captura del dato hasta la visualización operativa y las pruebas de integración sin depender de servicios en vivo.
Lo mejor que me dejó fue criterio. Aprendí sobre modelos reactivos, backpressure, event loop y WebClient, pero sobre todo sobre algo más útil: cuánto sofisticar una arquitectura y cuándo merece más la pena mantener un monolito pequeño, claro y fácil de operar.