Santiago Valencia Vera.
Todos los sistemas

Estudio de imagen de catálogo

Una herramienta para enriquecer la fotografía de producto de un comercio electrónico. Un equipo compone capas sobre un lienzo, el servidor renderiza la imagen final y el resultado se publica de vuelta al catálogo de la tienda por lotes.

01El problema

Enriquecer imágenes de producto implicaba abrir una herramienta de diseño, editar a mano cada talla de cada producto, exportar y subirlas una por una al administrador de la tienda. Para un catálogo con muchas variantes por producto, el trabajo no escalaba, y nada registraba qué imágenes ya se habían procesado.

02Arquitectura
Esquema de arquitectura del estudio de imagen: editor de lienzo, renderizado en servidor tras validación por esquema, almacenamiento de objetos como origen de entrega y publicación por lotes al catálogo.

El editor corre en el navegador y trabaja por capas, guardadas como plantillas para que un mismo tratamiento se reaplique a toda una línea de producto. El renderizado ocurre en el servidor con un pipeline de procesamiento de imagen, nunca en el navegador, así la salida es idéntica sin importar quién exportó. La definición de capas que llega del cliente se valida contra un esquema antes de llegar al renderizador, y las descargas de recursos se limitan a un conjunto de dominios permitidos.

La publicación es la parte que había que cuidar. El render se sube primero al almacenamiento de objetos, porque la plataforma de la tienda ingiere las imágenes descargándolas desde una URL. Cada nombre de archivo lleva fecha y hash del contenido, ya que reutilizar un nombre deja la imagen vieja en caché de la red de entrega por días. Después el pipeline elimina solo los renders previos que reconoce como propios, nunca la imagen principal ni la de hover, y archiva el original que reemplazó para que el cambio sea reversible.

03Stack

Stack

  • Next.js
  • TypeScript
  • sharp
  • Zod
  • Supabase
  • Tailwind CSS

Integraciones

  • VTEX Catalog API
  • VTEX SKU file API
  • AWS S3
04Decisiones

Renderizar en el servidor en vez de exportar desde el lienzo fue la decisión que hizo posible la publicación por lotes. Un solo camino de código produce todas las imágenes, así un producto con muchas variantes es un ciclo y no una tarde de trabajo.

La regla de nombres existe por cómo cachean las redes de entrega de contenido. Un nombre único por render es la única forma confiable de garantizar que el comprador vea la imagen nueva, y de paso marca qué archivos produjo esta herramienta.

No tocar nunca la imagen principal fue una restricción dura desde el inicio. La herramienta suma imágenes al set del producto y limpia lo suyo, lo que evita que un render malo llegue a ser la cara de una ficha.

02 — Próximo proyecto

Tracemos la ruta.

santiagovalenciavera@gmail.com · Abierto a roles senior y proyectos seleccionados