Skip to main content
Automações são as partes de um app que rodam por conta própria — em um cronograma, ou quando um serviço externo envia um evento. Você as declara em um componente process em kazzle.config.ts. Um componente pode ter quantos triggers você precisar.

A estrutura

Duas coisas estão acontecendo aqui:
  • processMode escolhe o ciclo de vida — servidor de longa duração, ou uma execução única por trigger.
  • triggers[] lista os eventos que devem disparar este componente.
Os dois são independentes. Um servidor persistente pode ter um cron. Um processo efêmero pode ter um webhook. Escolha o ciclo de vida que se adequa à carga de trabalho e anexe quantos triggers quiser.

processMode

Triggers

Cada trigger tem um name (único dentro do componente), um kind, e — dependendo do modo — um schedule e/ou path.

Modo persistente — HTTP para o servidor

Quando um trigger dispara para um componente persistente, Kazzle faz POST no seu servidor no path declarado. A requisição carrega: Para triggers de webhook, o corpo da requisição original é encaminhado como corpo do POST. Para triggers de cronograma o corpo está vazio.

Modo triggered — uma execução por trigger

Quando um trigger dispara para um componente triggered, Kazzle executa o script de entrada do zero e aguarda sua saída. Não há path; o script aprende qual trigger disparou através de variáveis de ambiente.
Componentes triggered não têm máquinas ociosas em produção — eles iniciam por chamada e desligam na saída.

URLs de webhook

O segmento triggerName deve corresponder a uma entrada kind: 'webhook' em triggers[] daquele componente. Nomes de trigger desconhecidos retornam 404.

Resolução de cronograma

Expressões cron são de 5 campos (minuto, hora, dia do mês, mês, dia da semana) e resolução de minuto é o mínimo. Cronogramas sub-minuto são rejeitados na validação do manifesto.

Como as execuções são registradas

Cada disparo de trigger escreve uma linha process_runs com trigger_name, triggered_by, run_id e o status de saída da execução. Você pode consultá-las do seu próprio código ou inspecioná-las na visualização de execuções do app.

Ficando sem créditos

Uma execução com falha é registrada e registrada em log, mas o cronograma continua rodando em seu ritmo normal — uma execução instável nunca desativa o trigger. A única coisa que para uma execução é créditos: cada disparo de trigger é verificado contra o saldo do espaço, e enquanto o espaço está sem créditos (ou não tem cobrança configurada) as execuções são puladas com um 402. Isto é auto-recuperável — o cronograma permanece armado e o próximo disparo após você recarregar roda normalmente, sem retomada manual.

Adicionando automações depois

Um app simples pode começar sem triggers e ganhá-los depois — adicione um resumo diário, conecte Stripe, execute limpeza. O ciclo de vida do componente (processMode) e triggers (triggers[]) são independentes, então você pode alterá-los sem reescrever o resto do app.