Cloudflare Consolida o Pipeline cdnjs em Sua Própria Plataforma

A partir de 23 de junho de 2026, cdnjs funciona totalmente na Developer Platform da Cloudflare — Workers, Workflows, D1, Queues, Workers Cache, R2, KV e Containers. A migração encerrou uma divisão de seis anos onde a camada de distribuição de arquivos estava na Cloudflare e o pipeline de publicação rodava no Google Cloud Platform. cdnjs agora processa 108.000 requisições por segundo e 9 bilhões por dia em mais de 330 data centers, com uma taxa de acerto de cache de 98,6% e 48,3% do mercado de CDN JavaScript.

A divisão antiga foi justificada pelo timing. Quando Cloudflare moveu a camada de distribuição do cdnjs para Workers e KV em 2020, Workflows, Durable Objects, R2 e Containers ainda não existiam. Workers foram construídos para requisições HTTP de curta duração, não para pipelines multi-etapas que baixam tarballs do npm, executam compressão pesada em CPU e orquestram trabalho por horas. O pipeline de publicação — que monitora npm e GitHub por novas versões de bibliotecas, as baixa, as processa e escreve no edge — permaneceu no que existia: uma cadeia de Cloud Functions do GCP, uma VM executando git-sync e um repositório GitHub como fonte de verdade.

Esta arquitetura criou cinco pontos de dor concretos. O mais prejudicial foi a ausência de um rastreamento compartilhado. Uma única atualização de pacote passava por Cloud Functions, eventos de objetos do GCS, tópicos do Pub/Sub, uma VM git-sync e Workers KV antes de chegar ao usuário. GCP Logging tinha metade da história; Cloudflare Logpush tinha a outra. Nenhum correlation ID as vinculava. Resultado: uma versão que escrevia corretamente no KV mas falhava em pousar no GitHub funcionaria por semanas até que alguém percebesse que os dois armazenamentos haviam divergido. Nenhum alerta poderia disparar porque o sistema não rastreava o estado completo do pipeline.

O segundo ponto de dor era armazenamento split-brain. Arquivos viviam simultaneamente em Workers KV no edge e em um repositório GitHub designado como fonte de verdade. Nenhum era realmente autoritativo. Quando divergiam, não havia reconciliação automatizada. O pipeline em si era uma cadeia de funções conectadas através de eventos de bucket do GCS: uma função busca o tarball do npm e o coloca em um bucket; o evento dispara a próxima. Opaco, frágil e impossível de reproduzir de forma limpa.

A nova arquitetura colapsa isso em primitivos Cloudflare. Workflows substituiu a cadeia de Function do GCP, fornecendo orquestração de pipeline durável e observável com um único correlation ID em cada etapa. R2 substituiu GCS. D1 lida com metadados e estado. Containers assumem o trabalho de compressão pesado em CPU que não se encaixa no modelo de execução do Workers. O caminho de distribuição de arquivos — Workers e KV — permanece inalterado, razão pela qual as taxas de acerto de cache e características de latência se mantiveram estáveis durante a migração.

Um impulsionador não óbvio do tráfego cdnjs é geração de código por LLM. Quando ChatGPT, Claude ou Cursor geram uma demo HTML, eles recorrem a URLs cdnjs porque 15 anos de posts de blog, READMEs do GitHub e threads do Stack Overflow estão em seus dados de treinamento. O padrão de URL é consistente, versões são imutáveis e hashes SRI estão presentes para verificação da cadeia de suprimento. Essas propriedades são exatamente o que um modelo pode reproduzir sem alucinar uma dependência quebrada. O tráfego cdnjs não está diminuindo com a ascensão de bundlers — é sustentado por ferramentas de IA que substituíram tutoriais JavaScript ad-hoc.

O anúncio da Cloudflare reconhece que a migração não foi disparada por falha. O sistema antigo atingia mais de 98% de taxa de acerto de cache e funcionava sem interrupções. O disparo foi velocidade de desenvolvimento. Enviar algo novo ou corrigir problemas exigia coordenar implantações entre GCP e Cloudflare simultaneamente, com observabilidade dividida entre dois sistemas de logging que não compartilhavam nenhuma chave de junção. A nova stack elimina esse overhead de coordenação e consolida observabilidade em uma única superfície. Para arquitetos avaliando plataformas edge-first para pipelines críticos, o teste é se os primitivos da plataforma — workflows duráveis, armazenamento de objetos, containers — conseguem absorver o trabalho stateful de longa duração que serverless originalmente não conseguia gerenciar. Depois de seis anos de construção, a resposta da Cloudflare é sim.