Imagínate esta escena: más de 200 tours turísticos cruzados contra más de 100 agencias en una plataforma de gestión. Para revisar las tarifas de cada combinación, el proceso era destructivamente manual: entrar en el tour, buscar la agencia que te interesa, desplegar los precios, apuntar el dato en un Excel, volver al listado, hacer clic en el siguiente... y repetir el bucle cientos de veces. Matemáticamente, una locura de miles de clics imposibles de gestionar en el día a día.
Ver a mi mujer pasar mañanas enteras atrapada en ese laberinto infinito me hizo saltar la chispa de desarrollador: "Esto no puede estar pensado así. Tiene que haber una forma de verlo todo de un vistazo".
El "Momento F12"
Aprovechando que la curiosidad es el motor de cualquier programador (y el primer paso de cualquier analista), decidí abrir las DevTools de Chrome. Me fui directo a la pestaña de Network para cotillear qué pasaba por debajo mientras navegábamos por la web.
¡Premio! Descubrí que la plataforma cargaba los datos atacando a una API propia. La lógica por debajo era limpia: había una petición que traía el listado de tours, otra para las agencias, y una específica para las hojas de precios indexada por sus IDs.
En mi cabeza la solución se dibujó al instante:
- Lanzar una petición para recuperar todos los tours y agencias.
- Recorrer ambas listas de IDs mediante bucles
foranidados. - Atacar la URL combinada de agencia/tour para conseguir las hojas de precios.
- Pintar toda esa información organizada en una sola pantalla.
Matar dos pájaros de un tiro (el nacimiento de TourTracker)
Por aquel entonces (hace unos cuatro años), yo acababa de cambiar de empleo. Venía de una época un poco estancada picando código en Java 6 y Struts, y mi nuevo jefe me estaba ayudando a reciclarme a fondo con herramientas modernas: Spring Boot y React.
¿El laboratorio perfecto para entrenar lo aprendido? Construir la solución a este problema real.
En un fin de semana monté el primer prototipo. Utilicé Spring Boot en el backend para gestionar las peticiones a la API externa y React en el frontend para maquetar de golpe esa tabla unificada. Fue el entorno ideal para romper mano con la arquitectura moderna fuera del horario de oficina y fijar los conocimientos del día a día.
Lidiando con el rendimiento real (y los temidos 504)
Al poco tiempo de lanzar el "juguete", nos topamos con la cruda realidad del software: el rendimiento. Lanzar tantas peticiones cruzadas en bucle a una API externa cada vez que abrías la página saturaba el navegador y el servidor de origen nos devolvía errores de tiempo de espera (Gateway Timeout 504). Estábamos haciendo un ataque de denegación de servicio involuntario a la plataforma.
Para ser respetuosos con el servidor ajeno, rediseñé la estrategia por completo: creé una réplica de los datos en local. Añadí un botón de sincronización manual para cambios urgentes y programé un proceso nocturno automatizado.
¿La clave técnica? El backend gestionaba la descarga en hilos que esperaban tiempos prudenciales para evitar la sobrecarga y el bloqueo por rate limiting. Así, cada mañana (o tras pulsar el botón), el sistema disponía de los datos limpios, cacheados y listos para volar sin tocar la API externa en todo el día.
Cuatro años después...
Lo que empezó como un script de fin de semana para echar una mano en casa terminó convirtiéndose en una aplicación de gestión completa con pantallas de empresas, contactos, destinos y pasarelas multimoneda a la que bauticé como TourTracker.
Hace apenas unos días completé uno de los hitos que más ilusión me hacía: migrar toda la interfaz a Next.js y desplegarla con éxito en Vercel, aplicando todo lo que sigo aprendiendo día a día.
A veces pensamos que para tener un side project interesante en el portfolio tenemos que inventar el próximo Twitter. Para mí, la mayor satisfacción ha sido aplicar el código para solucionar un problema real del día a día, ver a mi "cliente favorita" trabajar feliz y, de paso, certificarme a mí mismo que el esfuerzo del reciclaje profesional había valido la pena.
