Izak's Photos

01Contexto

Izak's Photos es el sitio de un estudio de fotografía de retrato, bodas, editorial y viajes con base en Santo Domingo. El estudio es ficticio: Izak no existe, y los precios, las cifras del estudio y los testimonios son contenido de muestra para enseñar el producto. Lo que sí es real es el software: está en línea, guarda solicitudes y se despliega como cualquier sitio de un cliente.

El proyecto nació en mayo de 2024 en un repositorio que creó Job Nacor y en el que colaboramos: un sitio en React y Bootstrap con siete páginas y un formulario de contacto de cuatro campos. En junio de 2026 lo reconstruí desde cero y en septiembre lo llevé a producción. Hoy mantengo esta edición y el repositorio conserva la autoría de los dos.

02Problema

Un archivo amplio de fotografías tiende a convertirse en una cuadrícula genérica, y un sitio de fotógrafo tiene dos trabajos a la vez: lucir la obra y convertir la visita en una solicitud. Además, una foto que no se puede enlazar no se puede compartir, y en el teléfono todo lo que depende del ratón desaparece.

03Mi función

La reconstrucción de 2026 es mía: la interfaz responsive, la experiencia bilingüe, la galería y el visor, la API de reservas, el administrador, el rendimiento de las imágenes, el despliegue en Railway, las pruebas, la integración continua y la documentación.

04Restricciones

• Un solo servicio. Django sirve la API, el administrador y el build de Vite desde el mismo dominio.
• Sin subida de fotos. Las imágenes son archivos del build: añadir una requiere un despliegue.
• Sin correo saliente. Las solicitudes quedan en la base de datos y se atienden desde el administrador.
• Bilingüe escrito a mano. 256 cadenas en español junto a su versión en inglés, sin librería de traducción.

05Cómo lo construí

La versión de 2026 pasó de 25 dependencias de ejecución a 6 y de siete secciones a cuatro páginas —portada, galería, sobre mí y reservas— más una 404 propia. El modelo de contacto de cuatro campos se convirtió en una solicitud de reserva con diez, y el formulario habla con la API en camelCase mientras el serializador lo traduce a los campos del modelo.

En septiembre lo revisé en cinco anchos (1440, 1024, 768, 390 y 360 px) y en los dos idiomas, y corregí lo que esa revisión sacó a la luz antes de desplegarlo: enlaces compartibles, visor accesible, miniaturas WebP, límite de envíos, página 404 y una configuración de producción más estricta.

06Decisiones de arquitectura

• Mismo origen en producción. Django y WhiteNoise sirven el build con nombres con hash y compresión, y una ruta final devuelve index.html para las rutas de React. El formulario llama a /api/contact/, así que no hace falta CORS. En desarrollo, Vite y Django corren por separado.
• El estado de la galería en la URL. ?category= y ?photo=: una serie o una foto abierta se pueden enlazar, y las destacadas de la portada abren directamente la suya.
• Traducción propia y mínima. Un Context con t({ en, es }) que detecta el idioma del navegador, lo recuerda y actualiza <html lang>.
• Base de datos por configuración. SQLite en local y PostgreSQL si existe DATABASE_URL, sin cambiar código.
• Publicar sólo lo que funciona. Railway migra antes de publicar y comprueba /api/health/ antes de dar tráfico a la versión nueva.

07Rendimiento de las imágenes

La galería descargaba los JPEG completos para pintar miniaturas pequeñas: 9.303 KB en un teléfono. Un script genera ahora miniaturas WebP de 720 px, que pesan un 74 % menos que los JPEG (8.986 KB frente a 2.372 KB); el JPEG completo sólo se pide al abrir el visor. Recorrer la galería entera en un teléfono pasó de 9,3 MB a 2,4 MB. Cada foto reserva su proporción con su ancho y alto reales, y la página no salta al cargar.

08Accesibilidad y seguridad

• El carrusel de la portada tiene botón de pausa, se detiene al recibir el foco y no arranca solo con prefers-reduced-motion.
• El visor mantiene el foco dentro y lo devuelve a la miniatura al cerrarse; se recorre con las flechas o deslizando.
• Hay enlace para saltar al contenido, anillo de foco visible y un título de pestaña por página.
• La API de reservas admite diez solicitudes por hora y cliente, y un campo trampa acepta los envíos de bots sin guardarlos.
• Fuera de desarrollo, las cookies son seguras y la API navegable de DRF queda apagada.

09Desafíos

La revisión en varios anchos encontró defectos que a simple vista pasaban:

• Un marco irregular en cada miniatura. El botón que envuelve cada foto conservaba el relleno del navegador.
• Una cabecera que nunca desenfocaba el fondo. Con las dos formas de backdrop-filter escritas, el minificador de Vite 8 sólo dejaba la versión con prefijo.
• Un visor de 0×0 mientras cargaba. width y height no reservan espacio si el CSS los pisa con auto.
• Un selector de idioma flotante que tapaba fotos, paquetes y la confirmación de la reserva; ahora vive en la cabecera y en el menú.
• Una fecha en UTC en el título de cada solicitud del administrador, que no coincidía con la hora local de su creación.

10Diseño y UX

Fondo casi negro y dorado apagado para que las fotos lleven el color, una serif editorial (Fraunces) para los titulares y una sans (DM Sans) para el texto. La reserva cabe en una vista: se elige un paquete, se llena el formulario y un resumen se actualiza mientras se escribe. Si la red falla, el aviso lo dice y los datos siguen escritos; si la API rechaza un dato, se marca el campo exacto.

11Lo que no tiene

Para que nadie lo dé por supuesto: no hay pagos, ni cuentas de cliente, ni galerías privadas, ni subida de fotos desde el administrador, ni correo saliente: las solicitudes sólo aparecen en /admin/. Tampoco hay pruebas del frontend ni analítica.

12Sobre el contenido y las capturas

El estudio, sus precios, sus cifras y sus testimonios son de muestra, y el formulario de producción guarda solicitudes de demostración: no lo uses con datos reales. Las fotografías y las personas que aparecen en ellas tienen derechos aparte de los del código, y el sitio no las atribuye a un autor real. Las capturas se hicieron el 25 de septiembre de 2026 sobre el build de producción servido en local, con solicitudes inventadas en el administrador. Las pantallas con algún defecto visible se dejaron fuera.

13Aprendizajes

Las capturas automáticas encontraron tres defectos que la revisión a ojo no vio. Y los fallos más difíciles no estaban en la lógica: un reset de botones incompleto, un minificador que descartaba una propiedad y un tamaño que el CSS anulaba. Revisar el sitio en varios anchos, en los dos idiomas y con la red retenida fue lo que los sacó a la luz.

14Estado actual

En línea en izaksphotos.jonasjavier.dev como un solo servicio en Railway, con el repositorio público bajo licencia GPL-3.0, la integración continua en verde y 8 pruebas del backend que pasan. Es un estudio de demostración: no tiene clientes ni reservas reales, así que no publico cifras de uso.