La Raya · backend (1): de una web de pueblos a empezar de cero

Este es el primer post de un diario de desarrollo sobre La Raya · A Raia, un proyecto sobre la frontera entre España y Portugal —ese trozo de Extremadura y el Alentejo/Beira donde los pueblos están a tiro de piedra unos de otros pero la información vive en silos separados por una raya en el mapa—. Como en cualquier diario honesto, voy a contar también lo que no salió a la primera. Y la primera lección es justo de dónde vengo.

La idea, y la primera versión

La semilla es vieja. En febrero de 2025 abrí un proyecto Wagtail con una idea sencilla: una web de las poblaciones de la Raya, con sus fichas, sus imágenes, un carrusel bonito. Wagtail es una elección muy razonable para eso: es un CMS sobre Django, con un árbol de páginas, editor decente y una API de lectura ya hecha. Si lo que quieres es publicar contenido editorial, te ahorra muchísimo.

Hice lo típico: modelos de HomePage, Poblacion, entidades colgando de cada pueblo, un carrusel de fotos. Y luego… la vida. El proyecto se quedó quieto medio año largo.

Cuando lo retomé en septiembre, hice un par de reestructuraciones —"home → poblaciones → entidades", simplificar, simplificar más— y cambié la API antigua por una basada en DRF con filtros que de verdad funcionaban. Pero seguía siendo, en el fondo, una web de fichas que alguien tenía que rellenar a mano. Y ahí estaba el problema de raíz, aunque tardé en verlo.

El problema real no era técnico

Una web de pueblos de la Raya con contenido manual tiene un defecto fatal: nadie va a mantenerla. Yo no me iba a sentar cada semana a copiar la programación del cine de Mérida, las fiestas de Marvão o las noticias de Idanha-a-Nova. Y sin contenido fresco, una guía local está muerta.

Así que la pregunta dejó de ser "¿qué modelos necesito?" y pasó a ser "¿cómo se llena esto solo?". Eso cambia el proyecto entero: ya no es un CMS donde escribes, es un agregador que va a buscar eventos, noticias y sitios a docenas de fuentes (webs municipales, feeds RSS, calendarios iCal, agendas culturales) y los normaliza en un modelo común. Wagtail sigue valiendo —el árbol de páginas y el editor son útiles para lo que sí se cura a mano—, pero el centro de gravedad se mueve al pipeline de datos.

Cuando entendí eso, la versión de 2025 dejó de servirme. No por mala, sino porque estaba pensada para otra cosa.

Empezar de cero (sin drama)

En mayo de 2026 hice un commit que en el historial se llama, sin rodeos, "Rediseño completo: modelos, seguridad, API y migración a uv". Suena dramático, pero fue liberador. Tiré de la mayor parte de lo anterior y reconstruí sobre tres ideas claras:

• El dato manda. Los modelos (LocalidadPage, EventoPage, NoticiaPage, recintos…) se diseñan pensando en que la mayoría del contenido va a llegar scrapeado y hay que poder deduplicarlo, clasificarlo y fecharlo con fiabilidad.
• Una base sólida de plataforma. Migré la gestión de dependencias a uv (rápido, reproducible), añadí autenticación JWT con una app accounts, y empecé a tipar en serio los serializers. Pequeñas cosas que se pagan solas a los dos meses.
• Pensado para desplegar. Desde el principio: Docker, Postgres y Redis, en vez de "ya lo dockerizaré luego" (spoiler de un capítulo futuro: el "luego" duele).

¿Por qué reescribir en lugar de refactorar poco a poco? Porque la versión vieja respondía a una pregunta equivocada ("¿cómo publico fichas?") y la nueva responde a otra ("¿cómo agrego y normalizo contenido de fuentes heterogéneas?"). Cuando la forma del problema cambia, arrastrar la arquitectura antigua suele costar más que rehacerla. No siempre —reescribir es la trampa clásica del programador—, pero aquí el código viejo era poco y la claridad nueva era mucha.

Lo que me llevo de este arranque

Tres cosas que me repito desde entonces:

1. Un proyecto sin un mecanismo de auto-alimentación es un proyecto que te abandonará a ti. Si depende de tu disciplina semanal, está condenado. Mejor invertir el esfuerzo en que se llene solo.
2. Wagtail no fue un error; fue la respuesta correcta a la pregunta de 2025. Cambió la pregunta, no la herramienta. Y de hecho sigue ahí, conviviendo con el pipeline.
3. Empezar de cero está bien cuando el coste de arrastrar lo viejo supera al de rehacerlo. El truco es ser honesto sobre cuánto código vas a tirar de verdad. Aquí era poco.

En la próxima entrada entro en el rediseño en serio: cómo quedaron los modelos, por qué una API de dominio en DRF (y no solo la API genérica de Wagtail), JWT, y la migración a uv. A partir de ahí empieza lo divertido: enseñar a la máquina a llenar la guía ella sola.