Pokemon Team Builder · API

Contexto

El constructor de equipos necesitaba cuentas de usuario, persistencia de equipos y un catálogo de Pokémon fiable. Eso convertía el backend en el núcleo del proyecto: autenticación, modelo de datos y una fuente de datos que no dependiera de terceros en cada petición.

Arquitectura

API REST con Spring Boot 4 sobre PostgreSQL 17. Spring Security con JWT para la sesión y refresh tokens guardados en base de datos, de forma que se pueden revocar. Correos transaccionales por SMTP para verificación y recuperación de cuenta.

El catálogo de Pokémon se sincroniza desde la PokéAPI a tablas propias, así que las consultas de la aplicación nunca salen del servidor. Un panel de administración permite gestionar usuarios y relanzar la sincronización.

Decisiones

Persistir los refresh tokens en vez de usarlos sin estado cuesta una consulta más por renovación, pero permite cerrar sesiones de forma remota. El límite de peticiones por IP en los endpoints de autenticación frena la fuerza bruta sin castigar al resto de la API.

Qué haría distinto

Estudiaría la forma de los datos de la PokéAPI más detenidamente antes de diseñar el esquema. El esquema que tenía en mente era demasiado diferente de cómo los datos eran servidos.

Y escribiría los tests antes de desplegar. Llegaron cuando la API ya llevaba tiempo en producción y me di cuenta de que necesitaba los tests.