CuadrosJaci
Catálogo web para una artista, con su propio dominio.
- Python 3.12
- Django 5
- Django REST Framework
- PostgreSQL 16
- React
- Vite
- Docker
- pytest
El problema que solucionamos
Una artista que muestra su obra en redes sociales depende del algoritmo y no tiene forma de presentar el catálogo ordenado: por estilo, por técnica, por tamaño. Un cliente que pregunta por un cuadro específico termina revisando publicaciones viejas.
Qué hace
Un catálogo filtrable con dominio propio. El backend es una API de solo lectura, deliberadamente simple, y el peso está en el frontend y en que el sitio esté siempre disponible.
Arquitectura
Segunda aplicación en el mismo servidor que Caudal, compartiendo el reverse proxy pero con su base aislada. El frontend no se sirve con Node: se compila a archivos estáticos que entrega el proxy directamente.
Borde
Caddy
El mismo que sirve Caudal, con otro dominio y su propio certificado.
Aplicación
React + Vite (build estático)
Archivos ya compilados. No hay proceso de Node corriendo en producción.
Django REST Framework
API de solo lectura, sin autenticación. UUID como clave primaria.
Datos
PostgreSQL 16
- Los nombres de contenedores y volúmenes siguen una convención obligatoria: el respaldo del servidor descubre qué hacer a partir de ellos, y una aplicación que no la respeta queda sin backup en silencio.
- Se despliega desde un clon de git con una clave de despliegue de solo lectura, así el servidor no tiene permisos de escritura sobre el repositorio.
El desafío
Meter una segunda aplicación en un servidor que ya servía otra
El desafío real de este proyecto no fue el backend, que es simple a propósito. Fue que el servidor pasara de una aplicación a dos sin que la segunda pudiera romper a la primera: límites de memoria y CPU por contenedor para que una app con problemas no deje sin recursos a la otra, rotación de logs para que no llenen el disco en silencio, y una convención de nombres que hace que la app nueva quede incluida en el backup automáticamente. Una app que no respeta la convención queda sin respaldo sin que nadie se entere, que es la peor clase de falla.
Decisiones técnicas
Build estático del frontend servido por el proxyen vez deservir con el dev server de Vite
Porque El dev server no está hecho para producción: sin compresión, sin cacheo y con la superficie de ataque de una herramienta de desarrollo. El proxy sirve archivos estáticos y hace lo que sabe hacer.
UUID como clave primariaen vez deenteros autoincrementales
Porque Los IDs secuenciales en una API pública filtran cuántas obras hay y permiten recorrerlas enumerando. No es crítico en un catálogo, pero el costo de evitarlo era cero.
Qué aprendí
Que la segunda aplicación en un servidor es la que revela si el trabajo de infraestructura estaba bien hecho. Con una sola app, muchas decisiones parecen opcionales; con dos, cada una que faltaba se nota.
Qué sigue
Servir las imágenes subidas directamente desde el proxy, y ampliar los filtros del catálogo.
En resumen
- Sitio de cliente, en producción
- API REST de solo lectura, sin autenticación
- Desplegado desde un clon de git con deploy key de solo lectura