Uma frota pequena de sensores não precisa de um servidor ocioso o dia inteiro só para receber algumas medições. O ESP32 pode enviar lotes HTTPS limitados a um Worker, que valida identidade, esquema e autorização antes de gravar por um binding ou enfileirar trabalho. Serverless muda onde a operação acontece; não elimina identidade, retries, retenção nem tratamento de falhas.
HTTP funciona bem quando o equipamento reporta periodicamente e pode repetir uma requisição. MQTT pode ser melhor para pub/sub persistente ou comandos de retorno, mas não presuma que Worker seja um broker MQTT genérico. Endpoint HTTPS do Worker é uma fronteira simples de ingestão; compare suporte de protocolo e limites do serviço para a implantação real.
Não grave chave service-role do Supabase, senha do banco ou segredo compartilhado da frota no firmware. A credencial identifica uma unidade e autoriza apenas operações previstas. Conforme o risco e a capacidade de provisionamento, use credenciais individuais revogáveis ou assinatura de requisição com chave provisionada com segurança. Validar certificado do servidor TLS é obrigatório; autenticação do cliente pode usar token/assinatura ou arquitetura mTLS suportada.
Na assinatura, inclua método, caminho, ID do dispositivo, horário, nonce e digest do corpo. O Worker valida a assinatura em tempo constante, confere janela do relógio e registra nonce/ID de evento para rejeitar replay. Se o relógio estiver errado, desenhe bootstrap ou desafio do servidor; não desligue a checagem de validade em silêncio. Planeje rotação com sobreposição limitada e revogação de dispositivo perdido.
| Verificação | Motivo | Falha esperada |
|---|---|---|
| Método, rota e tipo de conteúdo | Reduzir superfície pública. | Rejeitar cedo requisições não aceitas. |
| Tamanho e quantidade do lote | Limitar parsing e custo de armazenamento. | 413/400 claro; dispositivo divide o lote. |
| Identidade e vínculo com cliente | Impedir gravação cruzada. | Rejeitar; nunca confiar no cliente enviado no JSON. |
| Esquema, unidade, faixa e data | Evitar telemetria corrompida ou ambígua. | Rejeitar ou colocar em quarentena com motivo. |
| ID, sequência e taxa | Controlar retries duplicados e abuso. | Retornar resultado anterior ou orientação limitada. |
Defina limites que caibam na memória do dispositivo e nas restrições do plano Cloudflare; limite elevado para uploads não torna lotes enormes uma boa escolha. Faça parsing de JSON limitado e valide campos explicitamente. Nunca concatene entrada em SQL. D1 oferece prepared statements: vincule parâmetros e obtenha ID autorizado da credencial validada, não de um campo JSON não confiável.
Para telemetria modesta, o Worker grava por binding D1 com prepared statement e chave idempotente. Simples, mas resposta de sucesso deve significar que a gravação durável terminou. Para picos ou trabalho lento, uma Queue desacopla aceite e processamento: confirme apenas depois de enfileirar, torne o consumidor idempotente, limite retries e defina dead letter. Fila não substitui política de retenção nem confirmação ponta a ponta.
Se o Postgres já opera em outro lugar, o Worker pode chegar por um caminho suportado, como Hyperdrive ou API de serviço; gestão de conexões e capacidade continuam importantes. Não escolha banco apenas porque aparece no mesmo painel de fornecedor.
O dispositivo mantém IDs ou sequências até a API confirmar aceite. Reintenta timeout com backoff exponencial e jitter: o servidor pode ter gravado antes de a resposta se perder, então o mesmo ID não pode criar outra linha. Retorne estados explícitos de aceito, duplicado, inválido e repetível. Limite lotes, fila local, política de disco cheio e alertas para quedas longas.
Autenticação de dispositivo e login do painel são domínios de confiança distintos. O painel chama API autenticada por usuário, com leituras limitadas a clientes e locais permitidos. Não exponha tokens do dispositivo ao JavaScript do navegador. Guarde credenciais do Worker em secrets criptografados ou bindings, não em configuração aberta, histórico Git ou logs. Oculte cabeçalhos de autorização, assinaturas e telemetria sensível.
Meça requisições aceitas/rejeitadas, duplicatas, atraso, idade da fila, erros de banco, silêncio por dispositivo e atualidade ponta a ponta. Teste assinatura vencida, replay, payload malformado, indisponibilidade de D1, esgotamento de retries, deriva do relógio, perda de rede e revogação. Confirme que as funções físicas seguras persistem offline.
Workers podem ser uma borda de API compacta para ESP32: autenticam a unidade, validam evento limitado e gravam ou enfileiram via bindings do servidor. Mantenha credenciais de banco longe do firmware, torne retries idempotentes, isole usuários do painel e trate filas, cotas, retenção e operação offline como requisitos.