Caso de estudio
F1nalLap
App full stack de Fórmula 1 con backend propio en Spring Boot y PostgreSQL, en producción.
Rol
Desarrollo completo (TFG ampliado)
Año
2025 – Presente
Stack
Java 21 · Spring Boot 4 · PostgreSQL · Angular 19
Resumen
F1nalLap empezó como mi Trabajo de Fin de Grado: una app en Angular con clasificaciones, calendario, resultados, comparativas y un simulador de estrategias de carrera. En la primera versión, el front llamaba directamente a una API externa y toda la lógica vivía en TypeScript.
Después del TFG lo amplié con un backend propio en Spring Boot y PostgreSQL, desplegado en Render. Ahora el front solo consume mi API REST versionada, y el simulador de estrategias vive en Java, cubierto por tests.
El reto
Depender en cada visita de una API externa que no controlo significaba heredar sus límites de peticiones, sus caídas y sus cambios de formato. Además, la lógica de negocio importante —el simulador— estaba en el navegador, sin tests y difícil de evolucionar.
El objetivo era mover los datos y la lógica a un backend propio: ingerir los datos una vez, guardarlos de forma consistente y servirlos con una API estable, sin perder ninguna funcionalidad del front.
Arquitectura y decisiones
Las piezas principales del backend y por qué están así:
- API REST versionada de clasificaciones, resultados, circuitos y estrategias, con errores en formato ProblemDetail, documentación en Swagger y caché HTTP por temporada.
- Ingesta programada desde la API de Jolpica con paginación, control de ritmo y reintentos con backoff ante respuestas 429 y 5xx. Cada temporada se escribe en una sola transacción, de forma idempotente: repetir la ingesta no duplica datos.
- Simulador de estrategias portado de TypeScript a Java: combina stints legales de 2 y 3 paradas, modela la degradación por compuesto y fase, y es determinista con semilla, así que se puede testear.
- Esquema gestionado con Flyway y Docker Compose para levantar todo el entorno en local.
- 26 tests de backend (JUnit, Testcontainers con un Postgres real y WireMock para la API externa) y 51 en el front, con CI en GitHub Actions para ambos y despliegue continuo en Render y Netlify.
Dificultades y aprendizajes
Estas son las partes que más me hicieron pensar:
Una fuente externa que no controlo
La API de Jolpica limita las peticiones y a veces falla. Diseñar la ingesta con control de ritmo, reintentos con backoff y escritura idempotente por temporada me enseñó a tratar la red como algo que va a fallar, no como una excepción.
Portar lógica sin romperla
Pasar el simulador de TypeScript a Java sin cambiar su comportamiento exigía poder compararlos. Hacerlo determinista con semilla fue la clave: con la misma entrada, el mismo resultado, y eso se puede fijar en tests.
Tests que se parecen a producción
Con Testcontainers los tests de backend corren contra un PostgreSQL real, no contra una base de datos en memoria que esconda diferencias. Con WireMock simulo la API externa, incluidos sus errores.
Iré ampliando esta sección según el proyecto evolucione.
Resultado
F1nalLap está en producción: front en Netlify, API en Render con PostgreSQL y documentación pública en Swagger. Pasó de ser un proyecto de fin de grado a un backend que mantengo como cualquier sistema real, con tests contra una base de datos de verdad, CI y despliegue continuo.