Aula interactiva · Clase 6Qué recordamos
Sesiones, inscripciones, pedidos, productos, eventos y trabajos pendientes.
Clase 6 · De demo a producto I
Dale memoria, identidad y automatización durable.
Pasamos de archivos y demostraciones a un producto que guarda estados en Supabase, protege cada fila y ejecuta procesos visuales en n8n sin duplicar efectos.
PostgresAuth + RLSn8n visualColas + idempotencia
Arquitectura mínima
La página deja de ser el producto completo.
NavegadorInterfaz, horario local y token del usuario.
→Supabase AuthIdentidad y sesión verificable.
→Postgres + RLSEstado durable y acceso por fila.
→n8nOrquesta trabajos del servidor.
→ProveedorEmail, CRM o servicio externo.
Separación crítica: el navegador usa la clave pública y el JWT del usuario. La credencial que puede saltarse RLS vive sólo en el servidor, una automatización controlada o un trabajo administrativo.
Supabase en lenguaje de negocio
Tabla, fila, política y función cumplen trabajos distintos.
Una instancia real
Una inscripción de una persona a una clase, con estado y consentimiento.
Quién puede ver o cambiar
La base aplica la regla incluso si el frontend comete un error.
Operación de negocio
“Inscribir en una clase” valida identidad, sesión, consentimiento y agenda en una transacción.
Cómo encontramos rápido
Optimiza patrones reales como “trabajos en cola listos para ejecutar”.
Qué dato nunca aceptamos
Estados inválidos, duplicados o referencias a una sesión inexistente.
Anon, authenticated y service role
Tres modos; no tres nombres decorativos.
| Modo | Uso correcto | No debe hacer |
|---|---|---|
| Anon | Cargar contenido público e iniciar autenticación. | No bypass de RLS ni credenciales administrativas. |
| Authenticated | Registrar la sesión elegida usando el JWT de esa persona. | No leer inscripciones ajenas ni ejecutar trabajos del servidor. |
| Service role | n8n, migraciones, backfills y jobs deliberadamente administrativos. | Nunca aparecer en HTML, JavaScript del navegador, logs públicos o Analytics. |
Separación práctica. La landing usa la clave pública y sólo ve lo permitido por RLS. La persona autenticada obtiene su identidad desde el token, nunca desde un campo editable. n8n trabaja del lado servidor con una credencial administrativa, pero sólo llama funciones y tablas previstas para el flujo. Si una clave de servicio aparece en el navegador, el diseño ya falló aunque la demo funcione.
n8n como orquestador
Un workflow visual también necesita contrato.
Trigger
Schedule o webhook con método, ruta, autenticación y respuesta explícitos.
EntradaClaim
Reclama un trabajo pendiente de forma atómica y evita que dos workers lo tomen.
LockTransform
Construye el payload sin mezclar datos personales con telemetría.
DatosAction
Llama al proveedor con timeout, respuesta completa y error observable.
EfectoReconcile
Guarda accepted, retry o dead_letter según la respuesta real.
EstadoError workflow
Centraliza alertas y contexto de diagnóstico sin fingir éxito.
OperaciónIdempotencia
Reintentar no debe enviar dos veces.
Clave estable
Una persona + una sesión + un tipo de recordatorio producen una sola identidad lógica.
UPSERT atómico
La base inserta o actualiza en una operación, sin “consultar y luego decidir”.
Cola con SKIP LOCKED
Cada worker reclama un trabajo diferente sin esperar ni duplicar.
Conciliación
Accepted no significa delivered. El estado conserva lo que el proveedor realmente confirmó.
idempotency_key = session_id + ':' + user_id + ':' + reminder_key
Estados del job:
queued → processing → accepted
↘ queued (retry)
↘ dead_letter
unsubscribed → cancelledUna clave idempotente representa la intención del negocio, no el intento técnico: por ejemplo, inscripción + clase + tipo de recordatorio. Dos clics o un timeout pueden producir varios intentos, pero deben converger en una sola inscripción y un solo trabajo pendiente. El historial conserva los intentos sin multiplicar el efecto externo.
Interacción · Verdad operacional
¿Qué puedes afirmar con esta evidencia?
Inscripción pendiente
Se envió el enlace mágico, pero la persona todavía no confirmó identidad ni el RPC.
Se envió el enlace mágico, pero la persona todavía no confirmó identidad ni el RPC.
Laboratorio de punta a punta
Construye la inscripción por clase.
Modela cuatro entidadesSesión, inscripción, recordatorio y evento de entrega.
Define restriccionesEstados válidos, unicidad e integridad entre tablas.
Protege con RLSUsuario autenticado registra lo propio; tablas privadas no se exponen.
Crea la operación RPCValida sesión abierta, consentimiento y fuente antes del upsert.
Dibuja el workflow n8nClaim, envío, conciliación, retry, dead letter y baja.
Prueba fallosDoble clic, token vencido, proveedor caído, cancelación y reintento.
La prueba termina con dos recorridos: el feliz confirma identidad, persistencia, cola y respuesta; el de recuperación repite la misma petición, simula proveedor caído y demuestra que el estado puede reanudarse sin duplicar. Un HTTP 200 aislado no acredita ninguno de los dos recorridos.
Observabilidad
Producto real significa poder explicar el estado.
| Pregunta | Fuente de verdad |
|---|---|
| ¿Quién se inscribió? | Fila confirmada por el RPC autenticado. |
| ¿Qué aceptó? | Texto, versión, timestamp y landing de origen. |
| ¿Qué se programó? | Jobs únicos por sesión y recordatorio. |
| ¿Qué intentó n8n? | Ejecución y transición del job. |
| ¿Qué aceptó el proveedor? | Status, mensaje del proveedor y timestamp. |
| ¿Qué midió GA4? | Señal agregada sin PII; nunca reemplaza la base operacional. |
Puente a la clase 7
El producto ya tiene memoria. Falta operarlo en Internet.
En la última clase montamos el sistema en un VPS, conectamos dominio y HTTPS, protegemos secretos y desplegamos con backup, validación y rollback.