Junio: arquitectura de software y los primeros cinco proveedores
Cerrada la definición en mayo, en junio diseñamos la arquitectura del backend y empezamos a ingestar operadores de verdad — primero cinco GTFS, cada uno con su dialecto.
De la definición al código
En mayo sabíamos qué quería el usuario: comparar autobuses regionales sin abrir quince pestañas. En junio tocaba responder cómo: GraphQL sobre PostgreSQL, ingesta nocturna, caché para la home y un admin separado para curar datos sucios.
No buscábamos microservicios ni moda arquitectónica. Buscábamos poder añadir un operador nuevo sin reescribir la búsqueda.
Cinco proveedores, cinco formas de llamar a lo mismo
Los primeros cinco feeds ya enseñaron el patrón que hoy conocemos:
- Paradas con nombres comerciales distintos para la misma acera.
- Rutas identificadas por `route_id` opaco mientras el usuario piensa en “Bilbao–Vitoria”.
- Horarios que no se cruzan solos cuando origen y destino vienen de operadores distintos.
Cada ingestión sumaba viajes al catálogo, pero también deuda de curación: sin StopPlaces canónicos, el autocomplete miente.
Qué aprendimos
- Hace falta una capa de Place encima del GTFS crudo.
- La búsqueda multi-operador es un producto de datos, no solo de UI.
- Conviene contar en voz alta cuánto crece el catálogo — por eso publicamos cifras en Sarebus Empresas.
Siguiente hito en el diario: pasar de cinco a doce operadores y descubrir que comparar destinos distintos escala peor que esperábamos.