Una flota pequeña de sensores no necesita un servidor encendido todo el día solo para recibir mediciones. Un ESP32 puede enviar lotes HTTPS limitados a un Worker, que valida identidad, esquema y permisos antes de escribir mediante un binding o encolar trabajo. Serverless cambia dónde ocurre la operación; no elimina identidad, reintentos, retención ni gestión de fallos.
HTTP funciona si el dispositivo reporta por intervalos y puede reintentar. MQTT puede convenir para pub/sub persistente o comandos de retorno, pero no supongas que Worker es un broker MQTT genérico. Un endpoint HTTPS ofrece una frontera sencilla de ingesta; verifica protocolos y límites del servicio para tu despliegue concreto.
No incluyas en el firmware una clave service-role de Supabase, contraseña de base de datos ni secreto compartido de toda la flota. La credencial debe identificar una unidad y autorizar solo sus operaciones. Según el riesgo y el aprovisionamiento, usa credenciales individuales revocables o firma de solicitudes con claves instaladas de forma segura. Validar el certificado del servidor TLS es obligatorio; la autenticación del cliente puede añadirse con token/firma o una arquitectura mTLS compatible.
Firma método, ruta, ID del equipo, hora, nonce y digest del cuerpo. El Worker valida la firma, revisa la ventana temporal y registra nonce/ID del evento para impedir replay. Si el reloj deriva, diseña un bootstrap o reto del servidor; no desactives controles de vigencia en silencio. Planifica rotación con solapamiento acotado y revocación ante pérdida.
| Control | Motivo | Respuesta al fallo |
|---|---|---|
| Método, ruta y tipo de contenido | Reducir superficie pública. | Rechazar pronto lo no admitido. |
| Tamaño y cantidad del lote | Limitar análisis y coste. | 413/400 claro; el equipo divide el envío. |
| Identidad y vínculo con cliente | Evitar escrituras entre equipos. | Rechazar; no confiar en el cliente declarado en JSON. |
| Esquema, unidades, rango y hora | Evitar telemetría ambigua o dañada. | Rechazar o aislar con código de motivo. |
| ID, secuencia y tasa | Controlar duplicados y abuso. | Devolver resultado anterior o reintento acotado. |
Limita payload para la memoria del equipo y el plan de Cloudflare; permitir cargas grandes no convierte lotes enormes en buen diseño. Analiza JSON acotado y valida campos. Nunca concatenes entradas en SQL: D1 ofrece prepared statements. Vincula parámetros y obtiene la identidad autorizada desde las credenciales verificadas, no de un campo JSON manipulable.
Para telemetría moderada, el Worker escribe mediante binding D1 con consulta preparada y clave idempotente. Mantiene el flujo simple, pero el éxito debe significar que la escritura duradera acabó. Para picos o trabajo lento, Queue desacopla aceptación y procesamiento: confirma solo tras encolar, haz idempotente el consumidor, limita reintentos y define dead letter. La cola no sustituye retención ni acuse de extremo a extremo.
Si ya operas Postgres en otro sitio, Worker puede conectarse por una vía compatible, como Hyperdrive o una API de servicio; la gestión de conexiones y capacidad siguen importando. No elijas una base solo porque comparte panel de proveedor.
El equipo conserva IDs o secuencias hasta recibir confirmación. Reintenta timeouts con backoff exponencial y jitter: el servidor quizá guardó el evento antes de perderse la respuesta, así que el mismo ID no debe crear otra fila. Devuelve estados claros de aceptado, duplicado, inválido y reintentable. Limita lote y búfer local, define disco lleno y alerta durante cortes largos.
Autenticación de equipos y login del panel pertenecen a dominios distintos. El panel llama a una API autenticada por usuario y limitada a clientes/sitios autorizados. Nunca expongas tokens del dispositivo en JavaScript. Guarda credenciales del Worker en secrets cifrados o bindings, no en configuración visible, Git ni logs. Oculta cabeceras de autorización, firmas y telemetría sensible.
Mide solicitudes aceptadas/rechazadas, duplicados, retraso, edad de cola, errores de base, silencio por dispositivo y vigencia de datos. Prueba firma vencida, replay, JSON malformado, caída de D1, reintentos agotados, deriva de reloj, pérdida de red y revocación. Confirma que las funciones físicas seguras siguen operativas offline.
Workers pueden ser una capa API compacta para ESP32: autentican una unidad, validan un evento acotado y escriben o encolan mediante bindings del servidor. Mantén credenciales de base fuera del firmware, haz idempotentes los reintentos, separa usuarios del panel y trata colas, cuotas, retención y operación offline como requisitos centrales.