A Cloudflare concluiu com sucesso a migração total do cdnjs, o popular CDN de código aberto para bibliotecas web, para sua própria Plataforma de Desenvolvedores, eliminando dependências externas de nuvem.
- O cdnjs agora opera 100% sob a infraestrutura de borda da própria Cloudflare.
- A migração eliminou dependências legadas no Google Cloud Platform, como Cloud Functions e Cloud Storage.
- O Cloudflare R2 tornou-se a fonte única de verdade dos ativos do cdnjs.
- A Cloudflare elevou os limites internos de Workers e Workflows para acomodar as 9 bilhões de requisições diárias.
O desafio de escala e a infraestrutura legada
O cdnjs já havia passado por uma modernização parcial em 2020, quando o fluxo de entrega de arquivos foi movido para os Workers e Workers KV. Essa mudança de arquitetura otimizou o tráfego normal de dados, mas manteve a infraestrutura de ingestão e publicação fragmentada fora de casa.
O pipeline de publicação original dependia do Google Cloud Platform. Um conjunto de 26 Cloud Functions divididas em shards alfabéticos monitorava constantemente o npm em busca de novos lançamentos de pacotes. Esses arquivos eram então salvos no Google Cloud Storage, enquanto o mensageria ficava a cargo do Pub/Sub. Adicionalmente, uma máquina virtual dedicada rodava o git-sync para sincronizar o repositório com o GitHub, cujo tamanho ultrapassou a marca de 1,1 TB de armazenamento compactado.
# publicidade
Esse fluxo fragmentado gerava latência de sincronização, complexidade no gerenciamento multicloud e custos desnecessários com serviços de terceiros, limitando a agilidade no empacotamento de novas versões das bibliotecas JS/CSS para a comunidade web.
- 26 Cloud Functions do GCP monitoravam o npm
- Repositório GitHub cresceu além de 1,1 TB de armazenamento
- Workers KV e Cloudflare Workers serviam os dados, mas a ingestão dependia do GCP
A nova arquitetura nativa: r2, workers e workflows
Com a nova arquitetura unificada, o Cloudflare R2 passa a ser a única fonte da verdade para todos os arquivos publicados pelo cdnjs. O Workers KV armazena apenas os metadados dos pacotes, suas respectivas versões e as hashes de integridade (SRI - Subresource Integrity). Um Worker dedicado lida com as requisições de entrega, enquanto a camada padrão de Workers Cache garante que a maior parte das requisições nem sequer precise consultar o R2.
A orquestração do pipeline de ingestão foi completamente reescrita usando o Cloudflare Workflows. Um fluxo agendado varre o npm e o GitHub em busca de novas atualizações. Ao encontrar pacotes inéditos, o workflow faz o download dos arquivos diretamente para o R2 e dispara rotinas paralelas para extração, minificação e compressão. Ao final de cada execução, o índice de busca hospedado na Algolia é atualizado instantaneamente.
Para assegurar resiliência em cenários críticos, a Cloudflare também implementou um espelhamento preventivo de arquivos de contingência no DigitalOcean Spaces, acionado automaticamente caso ocorra alguma falha pontual de comunicação com o R2.
- R2 assume papel de armazenamento principal de ativos
- Cloudflare Workflows substitui as tarefas agendadas do GCP
- Workers KV agora foca exclusivamente em metadados rápidos e SRI hashes
Desafios de engenharia: integridade, compressão e limites de plataforma
A migração de um serviço crítico como o cdnjs impôs severos desafios de engenharia à equipe da Cloudflare. O principal deles foi a preservação exata dos bytes dos arquivos. Como muitos websites utilizam SRI (Subresource Integrity) para garantir que as bibliotecas carregadas não foram alteradas de forma maliciosa, qualquer mínima diferença gerada pelos algoritmos de minificação ou compressão invalidaria as hashes e quebraria milhares de sites globalmente.
A compressão também trouxe um gargalo de hardware: os algoritmos exigem o carregamento de bibliotecas inteiras em memória antes da gravação. Como os Workers tradicionais operam sob limites restritos de uso de CPU e memória, a Cloudflare contornou o obstáculo integrando o Cloudflare Containers para rodar os processos de compactação pesada, ao mesmo tempo em que estuda pipelines de streaming para o futuro.
Além disso, para suportar a escala massiva do cdnjs, a Cloudflare precisou elevar os limites operacionais de seus próprios produtos. O limite de subrequisições (subrequests) por Worker saltou de 1.000 para impressionantes 10 milhões, enquanto a capacidade máxima de etapas em uma execução do Cloudflare Workflows foi estendida de 1.024 para até 25.000 passos configuráveis. Graças a esse esforço, a plataforma de desenvolvimento da Cloudflare atingiu um novo nível de robustez para clientes empresariais.
| Componente | Arquitetura Legada (Híbrida) | Nova Arquitetura (Cloudflare Native) |
|---|---|---|
| Armazenamento de Arquivos | Google Cloud Storage / GitHub | Cloudflare R2 |
| Orquestrador de Ingestão | 26 Google Cloud Functions | Cloudflare Workflows |
| Sinalização e Filas | Google Cloud Pub/Sub | Cloudflare Queues / Workflows |
| Processamento de Compressão | Máquinas Virtuais dedicadas | Cloudflare Containers |
| Armazenamento de Metadados | Arquivos JSON no GitHub / KV | Workers KV / Durable Objects |
Arraste para o lado para ver toda a tabela.