La idea: un catálogo curado de radios para Latinoamérica

Quiero construir una app móvil para escuchar radios de Latinoamérica. La idea no es nueva, ni original. Pero las primeras versiones, las de juguete, suelen estrellarse contra la misma pared: ¿de dónde saco los datos?

¿No vale con radio-browser?

radio-browser.info es la respuesta corta. Es una base de datos comunitaria, federada (varios servidores espejo) y con una API JSON pública. Si quieres "una lista de radios", ya existe. Más de 30.000 emisoras dadas de alta por la comunidad.

Entonces, ¿por qué montar un backend propio?

Esa fue la primera decisión real del proyecto, y la primera que merece justificarse en voz alta antes de escribir una línea de código. Mis razones:

1. Curación. radio-browser es comunitario: cualquiera puede dar de alta una emisora, con cualquier nombre, sin filtro. Solo en LATAM hay miles de duplicados, streams con URLs muertas, emisoras en HTTP plano (que iOS rechaza), y registros con países mal etiquetados. Necesito un paso intermedio que decida qué entra y qué no.

2. Geografía. La app va a usar la ubicación del móvil para sugerir "emisoras cerca". Eso implica almacenar coordenadas, buscar por proximidad y devolver al cliente solo lo que le importa. PostGIS o SpatiaLite hacen ese trabajo mejor que la app.

3. Latencia y oferta agregada. Si la app llama a radio-browser directamente, cada GET paga el round-trip hasta el servidor de la federación, en otro continente. Con el backend sincronizado, sirvo en decenas de milisegundos desde mi servidor.

4. Soberanía. Si mañana radio-browser cambia el formato, está caído un fin de semana, o pone cuota a las requests, la app no se cae. Tengo mi base.

5. Es un buen ejercicio. Lo dije y lo digo: proyectos pequeños como este son los que mejor sirven para masticar tecnologías sin tener que justificarlas en un comité.

Lo que el backend no es

Igual de importante: qué no hago.

• No es un proxy de streaming. El cliente reproduce el audio directamente. El backend solo entrega la URL.
• No es un sistema de favoritos. Eso vive en el móvil, al menos por ahora.
• No es un CMS de emisoras. No hay registro de usuarios ni alta manual desde un panel público.
• No tiene login de usuarios finales. La API es pública y de solo lectura.

Esto último es interesante: la mayoría de tutoriales de Django+DRF empiezan con autenticación, registro, recuperación de password. Aquí decido que no. Y eso simplifica una capa entera del proyecto, como veremos cuando llegue la fase de auditoría.

El alcance, en una imagen mental

La app móvil consume la API REST de mi backend. El backend mantiene su propia base, sincronizada periódicamente desde radio-browser. Ni la app ni radio-browser saben nada el uno del otro.

En esta serie

Lo que viene en los siguientes posts va a documentar la construcción del backend, no en el orden de los commits (que es ruidoso), sino en el orden conceptual: desde las herramientas que elegí hasta cómo está cosido todo. Y voy a contar también las cosas que decidí mal la primera vez y que tuve que rehacer después de una auditoría que cambió bastante el diseño.

En el próximo capítulo, las piezas: por qué Django y no FastAPI, por qué SpatiaLite y no PostGIS (de momento), por qué descarté Celery, y cómo se relacionan entre sí.