Cloudflare Workers passam a aceitar TCP de entrada, e o gRPC é o primeiro protocolo em cima disso

Desde que a plataforma foi lançada em 2017, um Cloudflare Worker podia abrir sockets de saída para um banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → ou serviço, mas só conseguia atuar como servidor de HTTP. Um novo handler connect(socket) remove essa restrição: Workers passam a aceitar conexões TCP de entrada, e o gRPC é a primeira coisa construída sobre esse primitivo, segundo reportagem da InfoQ.

O anúncio saiu durante a Agents Week da Cloudflare, com o discurso girando em torno de voice AI↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →, onde baixa latência e uma conexão bidirecional persistente entre cliente e modelo importam. Mas a capacidade por baixo é mais ampla do que esse enquadramento sugere.

Três coisas foram lançadas juntas, com tetos diferentes

O handler connect(socket) aceita um socket bruto de entrada, roteado até um Worker através do Spectrum, o proxy de ingress da Cloudflare para tráfego não-HTTP. Um Worker pode ler e escrever no socket diretamente, entregá-lo a outro Worker ou passá-lo para um Durable Object:

export default {
  async connect(socket): Promise<void> {
    const writer = socket.writable.getWriter();
    await writer.write(new TextEncoder().encode("Hello, world!\n"));
    await writer.close();
  },
} satisfies ExportedHandler;

A partir de um Durable Object, o socket pode seguir para um Container via getTcpPort(), e é aí que o caminho full-duplex termina. Os exemplos da Cloudflare incluem um servidor gRPC echo em Go↳Go23 conteúdosEntendendo o Green Tea GC do Go 1.26Dev (Back & Front) · mai 2026Função recursiva em Go para acessar valores em mapas aninhadosDev (Back & Front) · set 2025Publicando projeto desenvolvido em Golang em um server grátisDev (Back & Front) · mar 2025Ver tudo em Dev (Back & Front) → e um socketserver em Python, ambos rodando sem modificação. Nas palavras da empresa, isso abre a porta para comunicação full-duplex entre cliente e servidor rodando qualquer programa, em qualquer linguagem, para qualquer protocolo baseado em TCP.

Os Workers em si recebem menos. Eles conseguem servir gRPC unário e server-streaming, e chamar servidores gRPC externos, sem um container, mas não streaming bidirecional. O mecanismo é tradução, não suporte nativo: o código do desenvolvedor usa gRPC-web, e a Cloudflare converte o gRPC de entrada em gRPC-web, e o gRPC-web de saída de volta em gRPC.

Por que não é suporte nativo

A razão é uma limitação de plataforma que o post explica diretamente. O HTTP/2 divide requisições em frames que carregam IDs de stream, e o gRPC depende desse controle em nível de stream para streaming, cancelamento, flow control e trailers. APIs de plataforma web como fetch() não expõem isso. Os navegadores têm o mesmo problema, e é por isso que o gRPC-web existe. A Cloudflare já converte gRPC para HTTP/1.1 dentro do seu reverse proxy desde 2020, para que regras de WAF e Bot Management possam inspecionar as mensagens.

O desenvolvedor Sebastian Buzdugan levantou a versão prática dessa limitação em resposta ao anúncio, perguntando se os Workers expõem controle de backpressure suficiente para streams gRPC, e observando que os casos de borda de streaming são o que decide se uma implementação se sustenta. O post não aborda isso.

O efeito prático é que clientes existentes não precisam de mudanças. Um Worker pode servir apps mobile usando grpc-swift-2 ou grpc-kotlin, ou ficar na frente de um backend gRPC existente do mesmo jeito que Workers já ficam na frente de APIs REST. O lado servidor exige poucas linhas com o pacote open-source @connectrpc/connect.

A parte mais franca do anúncio

O trecho mais honesto do texto é a Cloudflare explicando por que isso é beta privado, e não disponibilidade geral. A empresa não usa gRPC internamente:

Na Cloudflare, usamos Cap'n Proto e Cap'n Web e o sistema de RPC nativo em JavaScript embutido no Cloudflare Workers, em vez de gRPC. E quando lançamos algo, sempre buscamos estar usando aquilo nós mesmos.

Cloudflare, no anúncio de suporte a gRPC

É incomum um fornecedor publicar isso ao lado de um lançamento, e estabelece uma expectativa honesta. A Cloudflare diz que quer trabalhar com um conjunto menor de desenvolvedores gRPC primeiro e garantir que acertou a implementação antes de liberar para todos. Times avaliando isso devem ler como um sinal sobre maturidade, não como modéstia.

O que o primitivo destrava além do gRPC

Para times de plataforma, a pergunta é o que o primitivo habilita além do caso de uso anunciado. Os Workers ficaram restritos a HTTP por oito anos, o que descartava categorias inteiras de workload: message brokers, proxies de banco de dados, protocolos binários customizados, qualquer coisa que espere um socket. Passar um socket de Worker para Durable Object para Container transforma a borda num ponto de terminação para TCP arbitrário, com lógica de roteamento em JavaScript à frente.

Essa posição de roteamento merece atenção. Um Worker vê a conexão antes de decidir para onde ela vai, o mesmo formato de um API gateway tomando decisões antes de encaminhar uma requisição, só que aplicado a sockets brutos em vez de HTTP. O que um Worker pode fazer com um socket nessa posição, em termos de inspeção ou política, não é coberto no anúncio.

O ângulo gRPC também chega num momento específico. A especificação MCP 2026-07-28 adicionou gRPC como transporte opcional ao lado do HTTP, e desenvolvedores que responderam ao lançamento notaram o quanto da infraestrutura de agentes acaba redescobrindo convenções de RPC que a antecedem. Um protocolo que o Google lançou há quase dez anos continua reaparecendo como a resposta para tráfego máquina-a-máquina.

O que isso muda para o dev brasileiro

Para quem usa ou avalia edge computing no Brasil, o recado direto é este: o marketing e a entrega não coincidem por completo. A cópia social da própria Cloudflare anunciou que o suporte a gRPC "já está disponível" e descreveu servir gRPC nativamente na borda sem camadas de tradução. Na prática, tudo está em beta privado atrás de um formulário de cadastro, o streaming bidirecional exige o caminho até um Container, e o que os Workers fazem sozinhos é tradução, não gRPC nativo.

Para times BR que rodam microserviços com APIs de baixa latência ou que já têm backends gRPC, isso significa uma possível peça de gateway na borda sem reescrever clientes mobile. Mas quem depende de streaming bidirecional ou de garantias de backpressure em produção deve tratar o release como sinal de direção, não como algo para colocar num roadmap de curto prazo. A Cloudflare diz que protocolos baseados em UDP são o próximo passo.

Fonte: InfoQ