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. Para explicar Workers, R2 e Hyperdrive juntos, vou acompanhar outra jornada: o envio de um documento privado por um cliente.

Direto ao ponto

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 formam uma arquitetura possível, sem obrigar a adoção conjunta. Se o sistema não recebe arquivos, R2 pode ficar fora. Se o banco está no D1, Hyperdrive não participa. A composição correta é a menor que completa a jornada e permite localizar uma falha.

A publicação termina antes do cadastro

O Astro gera HTML, CSS e JavaScript durante o build. Pages publica esse resultado e relaciona a versão ao commit quando o projeto usa integração com Git. Uma página quebrada pode ser comparada com a alteração que produziu o deploy.

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.

Para projetos novos, a orientação atual da Cloudflare aponta Workers como caminho para aplicações com arquivos estáticos. O site da Promovaweb representa uma instalação existente no Pages. Em ambos os formatos, separe os arquivos públicos do código que usa segredos e grava conteúdo persistente.

A execução no Workers precisa responder mais que sucesso

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 separação com duas sessões. O primeiro cliente envia o documento e consegue abri-lo. O segundo usa o mesmo identificador e recebe a recusa prevista. Encontrar o objeto no bucket confirma a gravação, mas não confirma 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. 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.

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, essa praticidade só permanece útil quando cada componente tem uma função reconhecível e a jornada pode ser conferida do navegador ao banco.