Bodan the Backend: de portafolio a plataforma editorial

Bodan the Backend comenzó como un portafolio técnico y evolucionó hacia una plataforma editorial bilingüe con administración de contenido, generación estática, APIs, automatización de noticias e integraciones con servicios de inteligencia artificial.

El objetivo no era construir únicamente una web para publicar artículos. Quería desarrollar un sistema que demostrara cómo diseño servicios backend, separo responsabilidades, controlo integraciones externas y convierto procesos manuales en flujos reproducibles.

En este caso explico las decisiones técnicas detrás del proyecto, la arquitectura de su API, las medidas de seguridad implementadas y los límites que todavía conserva. El problema inicial

Publicar contenido técnico en dos idiomas implicaba repetir demasiadas operaciones:

• Crear manualmente las versiones española e inglesa.
• Mantener sincronizados títulos, descripciones y metadatos.
• Actualizar índices y páginas de navegación.
• Generar URLs canónicas y relaciones hreflang.
• Gestionar imágenes, tiempos de lectura y contenido relacionado.
• Reconstruir y desplegar el sitio después de cada cambio.
• Verificar que una noticia apareciera correctamente en todas las vistas.

Este proceso funcionaba con pocas publicaciones, pero se volvía propenso a inconsistencias conforme crecía el contenido.

También quería incorporar actualidad tecnológica sin convertir el sitio en un agregador automático ni permitir que un modelo de IA publicara sin supervisión.

Objetivos técnicos#

Definí cinco objetivos principales:

1. Mantener el contenido público rápido, estático y rastreable.
2. Separar la administración editorial del sitio visible.
3. Automatizar tareas repetitivas sin eliminar la revisión humana.
4. Utilizar servicios dinámicos únicamente donde fueran necesarios.
5. Diseñar fallos controlados para bases de datos y proveedores externos.

La arquitectura resultante combina contenido generado previamente con una pequeña capa dinámica ejecutada en Cloudflare Workers. La arquitectura se divide en tres áreas.

Sitio público#

Los artículos y noticias se construyen como HTML antes del despliegue. El navegador recibe el contenido completo desde la primera respuesta y no necesita esperar una consulta a la base de datos para mostrar una publicación.

Esta decisión reduce la complejidad en producción, mejora el rastreo y evita que una caída de D1 afecte la lectura de artículos ya publicados.

Administración editorial#

El CMS se ejecuta en el entorno local y permite:

• Crear y editar publicaciones.
• Mantener las versiones española e inglesa.
• Guardar borradores.
• Programar publicaciones.
• Gestionar imágenes.
• Previsualizar contenido privado.
• Aprobar o rechazar noticias.
• Reconstruir las páginas públicas.

Los archivos Markdown permanecen como fuente editorial. Las páginas HTML generadas son artefactos de despliegue y no deben editarse directamente.

Servicios dinámicos#

Cloudflare Workers procesa las operaciones que requieren ejecución en tiempo real, como suscripciones, bajas, redirecciones canónicas y políticas de caché.

Cloudflare D1 conserva el registro local de la newsletter. Kit gestiona la confirmación, la entrega de campañas, los rebotes, las quejas y las bajas de correo.

Diseño de la API#

La API se dividió según su nivel de exposición y responsabilidad.

API pública

La superficie pública es deliberadamente pequeña:

POST /api/newsletter
POST /api/newsletter/unsubscribe

Una suscripción sigue este flujo:

Solicitud
   │
   ▼
Validar Content-Type
   │
   ▼
Normalizar correo e idioma
   │
   ▼
Comprobar consentimiento
   │
   ▼
Aplicar rate limiting
   │
   ▼
Guardar estado pending en D1
   │
   ▼
Registrar el correo en Kit
   │
   ▼
Enviar confirmación double opt-in

La API define respuestas diferenciadas para datos inválidos, métodos incorrectos, exceso de solicitudes y fallos temporales de proveedores.

API editorial#

La administración utiliza endpoints separados para sesiones, publicaciones y noticias:

POST /api/admin/login
POST /api/admin/logout
GET  /api/admin/articles
POST /api/admin/articles
PUT  /api/admin/articles/:slug
GET  /api/admin/noticias/items
PUT  /api/admin/noticias/items/:id
POST /api/admin/noticias/items/:id/image
POST /api/admin/noticias/items/:id/approve
POST /api/admin/noticias/items/:id/reject

Esta API no forma parte de la superficie pública desplegada. El CMS y los datos editoriales permanecen en el entorno de administración.

Automatización editorial con IA#

El pipeline de noticias obtiene candidatos desde fuentes RSS y Hacker News. Antes de procesarlos, valida que las URLs sean públicas y establece límites para el tamaño de las respuestas.

El flujo separa dos responsabilidades:

Fuentes
   │
   ▼
Obtención y validación
   │
   ▼
Modelo editor
   │
   ├── Rechazar
   ├── Enviar a revisión
   └── Aprobar como candidato
            │
            ▼
      Modelo redactor
            │
            ▼
      Revisión humana
            │
            ▼
        Publicación

El modelo editor evalúa el valor técnico, la calidad de la fuente y las posibilidades de aportar un análisis original. El modelo redactor solamente interviene cuando el candidato supera la primera evaluación.

Ningún modelo puede publicar directamente. La revisión humana sigue siendo obligatoria.

Seguridad backend#

La seguridad se incorporó dentro de los flujos principales y no como una capa añadida al final.

Entre los controles implementados se encuentran:

• Sesiones administrativas con cookies HttpOnly.
• Política SameSite=Strict.
• Protección CSRF para operaciones administrativas.
• Validación y normalización de entradas.
• Rate limiting para la newsletter.
• Restricciones de formato y tamaño para imágenes.
• Límites para feeds, documentos y respuestas externas.
• Bloqueo de direcciones privadas y locales en fuentes remotas.
• Verificación de redirecciones para reducir el riesgo SSRF.
• Secretos almacenados fuera del código.
• Respuestas de error que no exponen credenciales ni detalles internos.
• Cabeceras CSP, HSTS y políticas adicionales del navegador.

En la baja de la newsletter, la API devuelve la misma respuesta exista o no el correo. Esto evita utilizar el endpoint para comprobar quién pertenece a la lista.

Decisiones importantes#

Generación estática en lugar de renderizado dinámico#

Los artículos cambian con poca frecuencia y se leen muchas veces. Consultar una base de datos en cada visita habría añadido coste y puntos de fallo sin una ventaja proporcional.

Generarlos previamente permite servir contenido completo desde la infraestructura edge.

D1 solamente para estado dinámico#

D1 se utiliza para datos que necesitan modificarse durante la ejecución, como el estado de los suscriptores. El contenido editorial permanece en archivos versionables.

Separación entre editor y redactor#

Utilizar un solo modelo para elegir y escribir noticias mezclaba evaluación y producción. Separar ambas tareas facilita rechazar contenido débil antes de gastar recursos en redactarlo.

Revisión humana obligatoria#

La automatización reduce trabajo repetitivo, pero la responsabilidad editorial permanece en una persona. Esta restricción también ayuda a controlar errores factuales y contenido demasiado cercano a las fuentes originales.

Integraciones externas detrás del Worker#

Las claves de Kit y otros proveedores nunca se envían al navegador. El Worker valida la solicitud, ejecuta la integración y devuelve únicamente el estado necesario.

Resultado#

El proyecto evolucionó hacia una plataforma capaz de:

• Generar publicaciones bilingües desde Markdown.
• Construir páginas completas con canonical y hreflang.
• Mantener un CMS separado del sitio público.
• Gestionar borradores, publicaciones y contenido programado.
• Obtener y evaluar noticias mediante un pipeline asistido por IA.
• Exigir aprobación humana antes de publicar.
• Gestionar imágenes editoriales y metadatos sociales.
• Registrar suscriptores mediante una API con consentimiento explícito.
• Integrarse con Kit para double opt-in y campañas.
• Desplegar contenido y APIs mediante Cloudflare Workers.
• Verificar contratos, seguridad y generación mediante pruebas automatizadas.

Actualmente el generador produce 18 páginas de artículos localizados a partir de 18 archivos Markdown en español e inglés.

Limitaciones actuales#

Bodan the Backend sigue siendo un producto en evolución.

Entre las mejoras pendientes se encuentran:

• Completar la activación productiva de Kit.
• Sincronizar mediante webhooks todos los cambios de estado entre Kit y D1.
• Incorporar pruebas E2E con navegador.
• Dividir algunos módulos que todavía concentran demasiadas responsabilidades.
• Publicar los primeros experimentos reproducibles en el Lab.
• Añadir métricas reales de uso y rendimiento cuando exista suficiente tráfico.

Estas limitaciones se mantienen visibles porque el objetivo del proyecto no es presentar una arquitectura perfecta, sino documentar decisiones reales y su evolución.

Aprendizajes#

La principal lección fue que una aplicación no necesita convertir todo su contenido en datos dinámicos para justificar un backend.

Separar el contenido estático de las operaciones dinámicas permitió mantener una superficie pública rápida mientras el sistema incorporaba un CMS, APIs, automatización editorial, IA y newsletter.

También confirmó que la automatización más útil no es la que elimina todas las decisiones humanas. Es la que reduce trabajo mecánico y deja visibles los puntos donde todavía se necesita criterio.