Compiler Explorer e a promessa de URLs que duram para sempre

• Compiler Explorer inicialmente usava uma abordagem de armazenar todo o estado diretamente na URL
• Conforme as URLs ficavam longas demais, foi adotado o serviço de encurtamento de URL goo.gl, do Google, o que acabou criando uma complexidade com vários redirecionamentos
• Desde 2018, por causa do problema de limite de tamanho das URLs e da dificuldade de manutenção, a estrutura foi migrada para um armazenamento próprio baseado em S3 e DynamoDB
• Porém, como o Google encerrará o serviço goo.gl em agosto de 2025, a situação passou a exigir que a persistência dos links antigos fosse gerenciada pelo próprio projeto
• Até o momento, mais de 12.000 links legados foram resgatados, mostrando a importância da preservação do conhecimento em programação e da operação sustentável de serviços

---

Garantia permanente e história dos links do Compiler Explorer

Modelo inicial e por que o goo.gl foi adotado

• Em 2012, o Compiler Explorer adotou uma estrutura que codificava diretamente na URL todo o estado do compilador
• À medida que a quantidade de informação de estado aumentava, surgiu o problema de URLs excessivamente longas
• Para encurtar as URLs, em 2014 foi aplicado o serviço de encurtamento goo.gl, do Google
  • Ele oferecia links curtos no formato goo.gl/abc123, que ao serem clicados redirecionavam para a URL longa original e restauravam o estado
• O Stack Overflow passou a proibir o uso de links encurtados em 2016, o que impôs limitações ao modelo existente
  • Todos os links baseados em goo.gl foram afetados por causa do risco de ocultar links maliciosos
• Como não se queria armazenar dados de usuários, foi criado como solução temporária um caminho próprio no formato godbolt.org/g/abc123
  • Ao acessar godbolt.org/g/abc123, havia novo redirecionamento para goo.gl/abc123
  • Desse ponto, o fluxo retornava por fim para a URL longa do godbolt.org
  • Com vários redirecionamentos, a estrutura acabou ficando complexa
• Depois, o uso da API do Google simplificou parte desse processo de redirecionamento

Introdução do armazenamento próprio e gestão dos links

• A partir de 2018, os limites de tamanho de URL e o incômodo da compressão de dados passaram a ser problemas frequentes
• Foi implementada uma estrutura própria usando S3 e DynamoDB
  • Os valores de entrada eram transformados em hash e armazenados no S3 como documentos JSON
  • Ao acessar um link curto (godbolt.org/z/hashbit), o mapeamento era consultado no DynamoDB
  • Foi implementada uma verificação para contornar casos em que o valor do hash contivesse palavrões ou termos inadequados, adicionando um elemento aleatório
  • Isso tratou o problema de links baseados em hash com conteúdo impróprio e houve bugs relacionados no caminho (por exemplo, issue #1297)
• O formato de endereço godbolt.org/g/abc123 continua sendo suportado até hoje
• Apesar do anúncio oficial do Google, o serviço goo.gl entrou em modo somente leitura e será encerrado por completo em agosto de 2025
• Links curtos baseados em goo.gl deixarão de poder ser resolvidos
• Como o formato godbolt.org/g/abc123 pode ter sua vida útil estendida por gestão direta, foi iniciado um trabalho estruturado de resgate desses links

Coleta em massa de links legados e trabalho de arquivamento

• Recentemente, foi feito um rastreamento e banco de dados de links legados a partir de todas as fontes possíveis (busca, dumps de dados, logs da web etc.)
  • API de busca na web do Google
  • API do GitHub
  • Logs do próprio servidor
  • Dump de dados do Stack Overflow no archive.org
  • Dados de páginas web arquivadas no Archive.org
• Cerca de 12.298 links curtos foram recuperados com sucesso
• Internamente, o projeto passou a usar seu próprio banco de dados de links no lugar do goo.gl (PR relacionada: #7724)
• Também pretende continuar coletando e preservando links godbolt.org/g/abc123 que ainda não tenham sido encontrados
• Se a comunidade ainda tiver links não registrados, a recomendação é acessá-los diretamente ou avisar os administradores para complementar o banco de dados

Filosofia do projeto e a importância de possuir a própria infraestrutura

• Este caso mostrou o risco de depender apenas da continuidade de serviços externos (como o Google) para infraestrutura crítica
• O gerenciamento de links curtos e a estrutura de backup eram medidas temporárias, e prometer URLs realmente permanentes exige administrar diretamente todo o serviço
• No processo de resgatar links legados antigos, quase como uma arqueologia digital, ficou claro que cada link é um vestígio do compartilhamento de conhecimento, de perguntas e de explicações de conceitos feitas por alguém
• Esse trabalho de armazenamento e preservação está ligado também ao arquivamento da história da comunidade de programação
• Se você encontrar um link antigo do Compiler Explorer, clicar nele agora também é uma forma de contribuir para a preservação do conhecimento na internet
• Desta vez, ao depender de uma infraestrutura sob controle direto, e não de terceiros, tornou-se possível cumprir a promessa de garantir sua continuidade

Disclaimer

• Este texto foi escrito por uma pessoa, e LLMs foram usados no processo de sugestão de links e revisão gramatical

[GN⁺]

Comentários no Hacker News

• Antes de 2010, parecia natural assumir que links duravam para sempre, então eu usava bastante o recurso de favoritos do navegador, mas com o tempo vivi a experiência de ver muitos favoritos se tornarem praticamente inutilizáveis por causa de link rot; depois disso, criei o hábito de salvar páginas da web em PDF, e quando o modo leitor (Reader view) se popularizou, passei a copiar o conteúdo no modo leitor e salvá-lo em arquivos RTF
  • Uso a extensão SingleFile para arquivar todas as páginas que visito; a instalação e a configuração são relativamente simples, mas é preciso ter em mente que isso consome bastante espaço de armazenamento; por exemplo, meu diretório de arquivo de páginas da web chegou a 1,1 TB link do GitHub do SingleFile
  • Se você instalar a extensão oficial do navegador Web Archive, pode configurá-la para arquivar automaticamente todas as páginas que visita
  • Meu método é lembrar das informações importantes, ou pelo menos de onde posso encontrá-las; como ainda estou vivo, esse método aparentemente funciona de algum jeito
  • Fico curioso se existe alguma extensão de navegador que redirecione automaticamente para web.archive.org quando um link expira por timeout
  • Há também a opção de usar o formato WARC junto com o WebRecorder informações sobre WARC, WebRecorder
• Talvez valha a pena colaborar com o projeto Goo.gl da ArchiveTeam detalhes do projeto; encurtamento de URL realmente parece ter sido uma das piores ideias explicação da URLTeam
  • Segundo o status em tempo real do projeto, 7,5 bilhões de URLs goo.gl já foram descobertas entre 42,5 bilhões no total link do status em tempo real
  • É provável que a ArchiveTeam tenha usado força bruta nos URLs encurtados do Goo.gl, e não links “conhecidos”; imagino que a maior parte, ou talvez todos, os URLs do Compiler Explorer estejam incluídos nos dados deles, então entrar em contato parece uma boa ideia
• A ideia de que URLs duram para sempre era um sonho idealizado; na prática, 99% dos URLs não são permanentes, então talvez faça mais sentido construir tecnologia partindo do pressuposto de que a infraestrutura não é permanente, em vez de continuar insistindo numa batalha perdida
  • Construir tecnologia assumindo que a infraestrutura não é permanente é o caminho certo, e também acho que devemos evitar usar serviços de encurtamento de URL como se fossem infraestrutura
  • URN (Uniform Resource Name) é um sistema criado para dar identidade a um recurso independentemente de sua localização, mas nunca se popularizou; no fim, os serviços de encurtamento de URL foram só uma tentativa parecida, sem implementar esse conceito direito explicação da Wikipédia sobre URN
  • Nomes de domínio frequentemente mudam de dono, e até URLs que parecem permanentes podem com o tempo se transformar em links maliciosos de phishing
  • Um URL identifica apenas a localização de um recurso na rede, não o recurso em si; por isso ele não precisa ser permanente nem único — daí o nome Uniform Resource Locator; esse problema já era reconhecido, e por isso o Digital Object Identifier foi inventado em 1997
• Há algo de poético em abusar de um serviço de encurtamento de links como se fosse um banco de dados e depois ter de sair procurando esses links preciosos novamente pelos cantos da internet
  • O propósito original do encurtamento de URL era tornar URLs longos mais curtos; o verdadeiro problema, na minha opinião, são as pessoas que abusam desses domínios para esconder spam, golpes e sites ilegais por trás de URLs encurtados
  • Pelo visto, eles também usavam o serviço apenas para comprimir URLs; na prática, o URL deles já continha o estado do compilador como se fosse um “banco de dados” por si só
• https://killedbygoogle.com/, Google Go Links (2010~2021) foi um serviço de encurtamento de URL do Google que operou por cerca de 11 anos e foi encerrado há 4 anos; clientes do Google Workspace também podiam usar domínios personalizados
  • Encerrar o serviço impedindo a criação de novos URLs encurtados (“minting new ones”) não me parece algo tão grave; muito pior é desativar também os URLs já criados, especialmente porque o próprio Google ainda continua usando esse recurso internamente em alguns apps
• A segunda coisa que mais me chamou a atenção foi a frase “Este texto foi escrito por uma pessoa, mas as sugestões de links e a revisão gramatical foram feitas por um LLM”; dá a sensação de estar vendo o começo de uma nova tendência
  • É interessante a realidade em que as pessoas sentem que precisam incluir esse tipo de aviso
  • Eu, pessoalmente, não vejo necessidade nenhuma desse tipo de aviso; se o conteúdo se sustenta por si só, isso basta, e se a qualidade do conteúdo for ruim, tanto faz se foi gerado por IA ou por uma pessoa; quem quer esse tipo de aviso talvez não tenha capacidade de avaliar o conteúdo por conta própria e o trate como uma espécie de atalho para presumir baixa qualidade em conteúdo gerado por IA
• É surpreendente que o Google queira encerrar até mesmo a versão somente leitura; fico me perguntando se manter redirecionamentos de links privados poderia gerar algum risco jurídico
  • Não sei exatamente qual é a situação interna, mas pode ser que eles queiram descontinuar porque o serviço em operação depende de bibliotecas ou runtimes antigos ou vulneráveis; no fim, mesmo que o custo seja pequeno, parece ser mais um caso de encerramento por redução de custos, com a impressão de que a empresa não se importa muito com boa vontade ou promessas feitas no passado
• Fico curioso se não existe absolutamente nenhuma forma de pedir a um funcionário do Google para extrair do banco de dados apenas os URLs encurtados que redirecionam para godbolt.org
• Sinceramente, a menos que alguma fundação com bastante recursos intervenha, tanto o Compiler Explorer quanto o godbolt.org também estão destinados a não ser eternos algum dia; talvez chegue um momento em que toda a informação passe a ser abstraída e contida em um modelo gigantesco com parâmetros imensos
  • Temos operado bem até agora; esta semana é o 13º aniversário, e mesmo que todos os patrocinadores deixem de apoiar, ainda temos recursos acumulados para continuar por mais de um ano; recentemente também temos pensado em criar uma fundação; na verdade, a vulnerabilidade real não é a falta de dinheiro, mas sim o fato de uma única pessoa (eu) ser o ponto único de falha
  • Faz sentido; agora, o momento em que um link do Compiler Explorer deixará de funcionar de verdade será quando o próprio Compiler Explorer desaparecer; até lá, os links devem continuar vivos; especialmente os links do Compiler Explorer em relatórios de bug têm muito valor, e eu também costumo incluir o código diretamente no relatório junto com o link, além de informar qual compilador e qual versão usei; não acho que o Compiler Explorer vá desaparecer tão cedo, mas deixar o relatório autossuficiente assim ajuda a se preparar para um desaparecimento inesperado
  • Isso me lembra a piada de que, segundo o teorema no-hiding, a informação sobrevive para sempre
• Manter um domínio também custa dinheiro, então não vejo como URLs poderiam durar para sempre; fico me perguntando se o desaparecimento de URLs talvez até tenha um lado positivo — a humanidade preserva especialmente as informações valiosas, e o resto some naturalmente na história
  • Mas historiadores querem mais até desses dados “lixo”, porque isso ajuda a entender melhor a vida real e o contexto da época; se fosse possível viajar no tempo, eu gostaria de saber como os historiadores daqui a mil anos olharão para este período em que a maior parte das informações desapareceu com a perda das mídias digitais
  • Eu também concordo com a ideia de que o desaparecimento de URLs tem aspectos positivos; escrevi algo relacionado sobre isso sobre a efemeridade da internet