Caso de estudio

F1nalLap

Motor de simulación probabilística de estrategias de carrera de F1.

Rol

Desarrollo completo (TFG)

Año

2025

Stack

TypeScript · REST APIs

Resumen

F1nalLap es mi Trabajo de Fin de Grado: una aplicación que ofrece a los aficionados de la Fórmula 1 información en tiempo real y simulaciones de estrategia de carrera. Bajo la superficie es un motor de simulación probabilística que consume datos históricos y en vivo desde APIs REST externas y los procesa con una arquitectura modular en TypeScript.

Quise tratarlo como un sistema de verdad, no como un proyecto de clase: tipado estricto, servicios desacoplados y separación clara entre la obtención de datos, la lógica de simulación y la presentación.

El reto

Los datos de Fórmula 1 viven repartidos en varias APIs externas, con formatos distintos, huecos y latencias que no controlo. El reto no era "pintar datos": era construir un sistema que siguiera dando una respuesta coherente aunque la fuente fallara, llegara incompleta o cambiara de forma.

Y por encima, generar una simulación de estrategia que fuera creíble a partir de grandes volúmenes de datos históricos, sin que la app se volviera lenta o inconsistente.

Arquitectura y decisiones

Estructuré el proyecto en módulos desacoplados para aislar cada responsabilidad:

  • Capa de acceso a datos que encapsula cada API externa detrás de una interfaz tipada, para que el resto del sistema no dependa de su formato concreto.
  • Tipado estricto de extremo a extremo en TypeScript: los datos externos se validan y normalizan antes de entrar en la lógica de negocio.
  • Motor de simulación independiente de la fuente de datos y de la UI, lo que permite probarlo de forma aislada.
  • Procesamiento de datos históricos separado del flujo en tiempo real para no penalizar la respuesta del usuario.

Dificultades y aprendizajes

Estas son las partes que de verdad me hicieron crecer como desarrollador:

Datos externos poco fiables

Las APIs no siempre devolvían lo esperado: campos ausentes, formatos cambiantes y caídas puntuales. Aprendí a no confiar nunca en la forma del dato externo y a normalizar y validar todo en la frontera del sistema.

Mantener la coherencia en tiempo real

Coordinar datos en vivo con el procesamiento histórico sin bloqueos ni estados inconsistentes me obligó a pensar con cuidado el flujo asíncrono y el manejo de errores.

Domar la complejidad con tipos

A medida que crecía, el tipado estricto pasó de ser una exigencia a ser mi red de seguridad: refactorizar dejó de dar miedo.

Iré ampliando esta sección con los problemas concretos que fui resolviendo durante el desarrollo.

Resultado

F1nalLap terminó siendo un sistema desplegado y funcional que defendí como Trabajo de Fin de Grado. Más allá de la nota, me dejó algo más valioso: la convicción de que la calidad del dato y diseñar pensando en el fallo no son lujos, sino la base de cualquier cosa que merezca la pena construir.