Integrar un workflow de ComfyUI en un sitio web no consiste solo en llamar una API. Un flujo usable necesita formulario, API backend, mapeo de parámetros, subida de imágenes, cola, polling de estado, almacenamiento de resultados y errores claros.
La forma segura es que el backend sea dueño del workflow JSON. El usuario solo modifica parámetros permitidos; el backend los inserta en la plantilla y envía la tarea a ComfyUI.
Separa dos capas de API
Hay dos capas:
- La API de tu sitio, llamada por el navegador.
- La API de ComfyUI, llamada por tu backend.
No expongas ComfyUI directamente a internet. Debe ser un servicio interno de render.
Bucle mínimo
|
|
Con esto ya tienes una primera versión.
Diseño de API backend
|
|
POST /api/generate debe crear la tarea y devolver taskId. No mantengas esa petición abierta hasta que termine la imagen.
Mantén tu propio estado
|
|
Aunque ComfyUI tenga queue e history, tu producto necesita un estado estable para la interfaz.
No dejes que usuarios envíen workflow JSON
El usuario solo debería controlar campos seguros:
- prompt;
- negative prompt;
- style;
- size;
- seed;
- imagen subida;
- strength o steps dentro de límites.
Aceptar workflow JSON arbitrario puede exponer modelos, nodos, rutas o tareas costosas.
Mantén mapeo de parámetros
|
|
Así puedes cambiar el workflow sin rehacer todo el frontend.
Subida de imágenes
Para image-to-image o referencia:
- Sube al backend.
- Valida tipo y tamaño.
- Guarda temporalmente.
- Pasa el archivo a ComfyUI.
- Borra al expirar.
No confíes solo en nombre de archivo o MIME del navegador.
Interacción del frontend
Debe mostrar:
- validación;
- progreso de subida;
- cola o generación;
- mensaje de espera;
- vista previa;
- reintento;
- error comprensible.
Un spinner infinito no basta.
Pseudocódigo de envío
|
|
Luego un worker o polling actualiza el estado.
Dónde guardar resultados
Opción 1: proxy desde backend
Sirve para herramientas internas pequeñas. El backend descarga desde ComfyUI y devuelve al navegador.
Opción 2: almacenamiento de objetos
Para sitios públicos, sube a S3, R2, OSS u otro storage. Guarda URL y metadatos en la base de datos.
Por qué necesitas una cola
La generación es lenta y la GPU es limitada. Sin cola, varios clics pueden saturar el servicio.
Controla:
- concurrencia;
- límites por usuario;
- reintentos;
- timeout;
- prioridad;
- uso de GPU.
Errores claros para usuarios
Convierte fallos internos en mensajes útiles:
- prompt inválido;
- archivo demasiado grande;
- generación agotó tiempo;
- modelo no disponible;
- cola llena;
- resultado expirado.
Los detalles técnicos deben quedar en logs.
Protecciones antes de producción
- autenticación o cuota;
- límites de subida;
- checks de prompt y contenido;
- límites de parámetros;
- control de concurrencia;
- timeout y cancelación;
- expiración de resultados;
- monitoreo de costes;
- allowlist de modelos y nodos;
- protección de APIs internas.
RunningHub o ComfyUI propio
RunningHub y servicios alojados reducen infraestructura y sirven para validar rápido. ComfyUI propio da control sobre modelos, nodos, coste GPU, datos y workflows personalizados.
Usa hosting para pruebas rápidas; self-hosting cuando necesites control.
Orden recomendado
- Ejecuta el workflow manualmente.
- Congela una plantilla.
- Expón pocos parámetros seguros.
- Crea API de tareas.
- Añade polling.
- Guarda resultados.
- Añade cola y límites.
- Añade monitoreo y limpieza.
- Agrega más workflows.
FAQ
¿El frontend puede llamar ComfyUI directamente?
No es recomendable en sitios públicos. Usa backend.
¿Hace falta WebSocket?
No al principio. Polling basta; WebSocket puede mejorar progreso después.
¿Pueden usuarios subir workflow JSON?
Normalmente no. Mantén workflows en backend.
¿Dónde guardar resultados?
En producción, object storage suele ser mejor que el disco de ComfyUI.
¿Un sitio puede usar varios workflows?
Sí. Usa IDs de workflow y mapeos separados.
¿Video e imagen se integran igual?
La estructura es parecida, pero video necesita más timeout, almacenamiento, cola y progreso.
Resumen
Trata ComfyUI como motor interno de render. El backend controla workflow, cola, estado, almacenamiento y límites. El frontend solo recoge entradas seguras y muestra progreso y resultados.