Uma publicação no Cloudflare Pages pode terminar assim que o navegador recebe os arquivos gerados pelo Astro. Já um formulário com anexo continua pelo Cloudflare Workers, grava um objeto no R2 e consulta um banco externo pelo Hyperdrive. O percurso da requisição define os componentes necessários.

No site da Promovaweb, eu uso o Cloudflare Pages ligado ao repositório Git. Ali, a publicação estática termina no deploy. O envio de um documento privado por um cliente exige outra jornada, com validação no Worker, armazenamento no R2 e registro no banco externo.

Direto ao ponto

O Pages serve o frontend produzido pelo build. No envio do formulário, o Worker valida a requisição, grava o documento no R2 e acessa o PostgreSQL ou MySQL externo por conexões reutilizadas pelo Hyperdrive. O log precisa relacionar essas etapas ao mesmo identificador.

Os quatro serviços podem compor a arquitetura sem exigir adoção conjunta. Neste exemplo, o R2 recebe o documento enviado e o Hyperdrive conecta o banco externo. Em outra aplicação, o bucket pode servir arquivos existentes sem formulário de upload. Escolha a menor composição que complete a jornada e permita localizar uma falha.

A publicação termina antes do cadastro

O Astro gera HTML, CSS e JavaScript durante o build. O Pages publica esse resultado e relaciona a versão ao commit quando o projeto usa integração com Git. Se a página quebrar depois do deploy, compare o erro com as mudanças do commit que publicou os arquivos. Para projetos novos, a documentação do Pages recomenda o Workers, que também publica arquivos estáticos.

O cadastro enviado pelo visitante não pertence a esses arquivos. Quando o formulário leva nome, email e documento, a aplicação precisa receber conteúdo novo depois da publicação. Colocar uma credencial no JavaScript do navegador permitiria que qualquer pessoa inspecionasse a chave, por isso o envio segue para um Worker.

O código que usa segredos e grava conteúdo persistente precisa executar fora do navegador. Essa separação também participa de uma futura mudança de fornecedor, detalhada em serviços da Cloudflare sem prender a stack.

Como os Cloudflare Workers validam um envio antes de gravar o anexo

O Worker recebe os campos, confere a sessão do cliente e valida tipo e tamanho do anexo. A origem permitida no navegador não substitui autorização, pois outra aplicação consegue chamar o endereço diretamente. O backend precisa relacionar a sessão ao cadastro que será alterado.

Uma chamada externa também pode terminar de três formas diferentes. O provedor recusa a requisição, aceita o trabalho e responde, ou aceita o trabalho sem devolver a resposta no tempo esperado. Repetir o envio sem distinguir esses estados pode gravar o mesmo cadastro mais de uma vez.

Inclua um identificador na requisição e preserve-o no log da função. Quando a interface mostra uma falha, esse valor permite encontrar a execução correspondente. O artigo sobre infraestrutura para Vibe Coding desenvolve essa passagem entre código gerado, serviços externos e resultados que precisam ser conferidos.

O arquivo não pode depender do próximo deploy

Depois da validação, o Worker grava o documento num bucket do R2. O arquivo fica separado do resultado estático do build, portanto uma nova publicação não o remove. O cadastro guarda o identificador necessário para localizar o objeto.

Um download privado pode passar novamente pelo Worker. A função confere a sessão e só então devolve o arquivo. Outra opção é emitir uma URL assinada pela interface compatível com S3. Durante a validade, qualquer pessoa que receba o endereço consegue usá-lo, por isso o prazo e o lugar onde a URL aparece fazem parte da implementação.

Teste a autorização com duas sessões: o primeiro cliente envia e abre o documento, enquanto o segundo recebe a recusa prevista ao usar o mesmo identificador. Encontrar o objeto no bucket confirma a gravação, mas não a autorização.

A consulta ainda chega ao banco de origem

O Hyperdrive recebe a conexão do Worker e reutiliza conexões com o PostgreSQL ou MySQL. Isso reduz etapas de transporte, criptografia e autenticação que seriam repetidas a cada abertura. O banco continua hospedado fora da Cloudflare, com a latência e a capacidade definidas na origem.

O cache de consultas exige atenção especial. Uma escrita não invalida automaticamente toda leitura armazenada, conforme a documentação do Hyperdrive. Se o cadastro acabou de mudar, uma consulta pode mostrar a versão anterior até a expiração configurada.

Reproduza a sequência real: atualize o cadastro e consulte-o logo depois. Para uma leitura que precisa refletir a gravação imediatamente, use a configuração sem cache indicada pela documentação. Compare também a conexão inicial com as chamadas seguintes para observar o efeito do pool.

Região, suporte e recuperação da máquina que mantém esse banco estão detalhados em como escolher um provedor de VPS. O Hyperdrive encurta etapas da conexão, mas não corrige uma consulta sem índice, um servidor sem capacidade ou uma origem distante da região atendida.

Filas entram depois da resposta ao navegador

Alguns trabalhos não precisam manter o cliente esperando. A função pode gravar o cadastro, publicar uma mensagem numa fila e devolver um identificador. Outro processo lê a mensagem e executa uma tarefa demorada, como extrair conteúdo do documento.

Uma mensagem pode reaparecer depois de uma falha. O consumidor precisa reconhecer o trabalho já concluído para não enviar outra notificação nem repetir uma cobrança. A aplicação define esse comportamento. A fila conserva o item pendente, mas não descobre sozinha se o efeito anterior já ocorreu. O artigo sobre AI Gateway, Vectorize e Agents examina a mesma distinção quando uma chamada ao modelo participa da tarefa.

O D1 atende outra função. Ele oferece um banco SQL baseado em SQLite dentro do ecossistema da Cloudflare. Escolhê-lo no lugar do PostgreSQL externo muda o modelo de armazenamento e de acesso, enquanto adicionar uma fila apenas separa o recebimento do processamento posterior.

Confira a jornada inteira depois do deploy

Abra a página publicada, envie um documento e acompanhe o mesmo identificador no Worker. Confirme a linha no banco, abra o objeto com a sessão correta e tente repetir o acesso com outro cliente. Em seguida, altere o cadastro e verifique se a leitura pelo Hyperdrive mostra o conteúdo novo.

Na conferência final, o commit identifica a interface publicada, o log do Worker mostra a validação, o bucket contém o objeto e o banco guarda o cadastro. Se uma etapa falha, o identificador da requisição leva você ao registro correspondente.

A Formação DevOps da Promovaweb ensina a publicar, observar e recuperar esse tipo de aplicação. Para uma segunda leitura recorrente sobre uma arquitetura já ativa, o Conselheiro de Tecnologia da Dev Side Studio acompanha infraestrutura, deploy e comportamento do sistema.

Eu gosto da praticidade da Cloudflare no site da Promovaweb. Para uma aplicação dinâmica, você precisa saber qual serviço responde por cada etapa e acompanhar a jornada do navegador ao banco.