- O JeffGeerling.com, operado com base em Drupal desde 2009, foi migrado para o gerador de sites estáticos (SSG) Hugo para aumentar a eficiência do blog pessoal
- As diversas atualizações e a carga de manutenção acumuladas do Drupal 6 ao 10 foram o principal motivo da mudança
- O Hugo oferece suporte à escrita baseada em Markdown, simplificando o processo de publicação antes complexo e permitindo executar publicação e deploy com uma única linha de comando
- Durante a migração, podem ocorrer alguns problemas como erros em links de imagens e perda de URLs, e os recursos de comentários e busca serão restaurados em uma etapa posterior
- Como exemplo para desenvolvedores independentes, mostra as vantagens práticas da migração para sites estáticos ao oferecer workflow enxuto e eficiência de manutenção
Contexto da migração do Drupal para o Hugo
- O site começou em 2009 com Drupal 6 e passou por upgrades graduais para 7, 8, 9 e 10
- O CMS, usado profissionalmente por mais de 10 anos, também vinha sendo aplicado ao blog pessoal
- Após o complexo processo de upgrade do Drupal 7 para o 8, foi se acumulando o cansaço de manter no blog pessoal uma Digital Experience Platform (DXP) voltada para uso corporativo
- O blog é usado como projeto pessoal e espaço complementar para conteúdo no YouTube, e a decisão de migrar foi tomada para focar mais na escrita do que na manutenção do CMS
Por que escolher o Hugo
- Já havia experiência anterior migrando sites de hobby para hospedagem estática, com alguns convertidos para Jekyll ou Hugo
- O Jekyll é adequado para GitHub Pages, mas, por não ser especialista em Ruby, houve preferência pela configuração simples e velocidade do Hugo
- O Hugo oferece suporte nativo a Markdown, integrando-se naturalmente ao modo de escrita já utilizado
Processo de migração e problemas
- O trabalho de migração está em andamento na issue #158 do GitHub
- Por causa de mais de 3.500 posts e 20 anos de dados, existe a possibilidade de alguns problemas com imagens, erros de links e redirecionamentos ausentes
- Está sendo feito o possível para manter a estrutura de URLs existente ou adicionar redirecionamentos
Melhoria no workflow baseado em Markdown
- Desde 2020, todos os posts são escritos em Markdown
- Antes, os textos eram escritos em Markdown no Sublime Text, convertidos para HTML e enviados manualmente ao Drupal
- No Drupal, publicar um post exigia um processo em várias etapas
- Colar o conteúdo, fazer upload e inserir imagens individualmente, ajustar a data de publicação, limpar cache etc.
- Isso incluía até gerenciamento de cache do Cloudflare para lidar com DDoS, tornando o processo complexo
- No Hugo, após escrever o arquivo Markdown, é possível publicar imediatamente com o comando
hugo && git commit && git push
- A carga de administrar Composer, Drush, PHP, MariaDB e Nginx desaparece, melhorando a eficiência de manutenção
Próximos planos (TODOs)
- O recurso de comentários será restaurado na segunda fase com um sistema de comentários estático auto-hospedado
- A busca no site antes era baseada em Apache Solr, mas atualmente está desativada
- A forma de implementar busca no Hugo está sendo avaliada na issue #168
- Na fase inicial da migração, os comentários estão desativados, e a portabilidade do conteúdo anterior deve levar tempo
O significado da mudança
- Saída da estrutura complexa de criação e gestão de conteúdo do Drupal para um modelo de operação de site estático mais simples e eficiente
- Um exemplo prático de como reduzir a carga de manutenção e criar um ambiente mais focado na produção para desenvolvedores independentes
- A migração para Hugo é vista como um caminho para aumentar a sustentabilidade da operação de um blog pessoal
1 comentários
Comentários do Hacker News
Há alguns anos, migrei meu site pessoal para um gerador de site estático baseado em Common Lisp feito por mim
No começo tinha umas 850 linhas, mas agora cresceu para cerca de 1500, e renderiza estaticamente quase tudo, incluindo posts do blog, livro de visitas, páginas de comentários e feeds RSS por tag
Como escrevo todo o código, HTML e CSS manualmente, consigo manter controle estético total e também adicionar recursos novos rapidamente
Por exemplo, para adicionar uma página de “backlinks”, bastaram umas 40 linhas de código em CL e 15 minutos
Agora está muito estável, então quase não preciso mexer nele e posso focar só em escrever
Eu gastava todo o tempo fuçando no motor do blog e no fim acabava não escrevendo
Então voltei de propósito para uma solução hospedada com menos controle. Agora consigo focar apenas em escrever
Antes eu mantinha um projeto público chamado Tclssg, e graças ao feedback dos usuários acabei documentando e adicionando muitos recursos
Mas, por ser um projeto público, era difícil mudar a estrutura livremente
Hoje uso um gerador para meu site feito de Python (900 linhas) + Pandoc Lua (700 linhas)
A evolução técnica está resumida no meu site
Agora estou refazendo em TypeScript/Bun, e ainda restam elementos com cara de LISP
Estou procurando um dialeto leve de LISP/Scheme que tenha SQLite e parsing de HTML embutidos e compile nativamente
Reuni informações relacionadas aqui
Mesmo depois de anos, ainda consigo fazer o build do site inteiro em menos de 1 segundo
Também adicionei RSS e destaque de código por conta própria, usando Chroma e Blackfriday
Testei o Hugo, mas achei complexo demais e acabei fazendo o meu
Antes migrei do svbtle para Hugo e, sinceramente, me arrependo
Fiz um fork do tema, mas o Hugo quebra com frequência e a manutenção consome tempo demais
Neste momento, o site simplesmente não compila
Se eu puder dar um conselho, é uma boa manter a versão binária usada para build junto no controle de versão
Geradores de site estático quase não têm questões de segurança, então, se não faltar nenhum recurso importante, dá para continuar usando a versão antiga mesmo
Desde que o sistema operacional ou a CPU não mudem muito, não deve haver problema
Eu também congelei a versão tomando esta configuração como referência
Para achar uma versão que funcione, o mais eficiente é usar busca binária
Como localmente e no CI uso exatamente a mesma versão do Hugo, não há espaço para esse tipo de problema
${project}/bin/, adicionar ao.gitignoree registrar o checksum em um arquivoSHA256SUMSÉ um esquema parecido com uma versão simples de Git LFS
Dá medo tentar alinhar as versões ao mudar para um computador novo, e no fim estou portando para PHP, mas ainda não terminei
Para quem escreve em Markdown, migrar para Hugo faz sentido
Eu também levei mais de 500 posts do Jekyll para Hugo, e a parte mais difícil foi a sintaxe dos templates
Ainda assim, no geral valeu a pena
Resumi o processo de migração e os scripts de conversão automática num post do blog
SSG é bom para sites estáticos, mas quando há necessidade de interação, acaba precisando de servidor
Se de qualquer forma você vai rodar um servidor, renderizar Markdown dinamicamente é mais simples
No fim, SSG só aumenta dependências e pontos de falha
Acho que o Jeff vai se arrepender quando tentar adicionar algo como comentários mais tarde
Pessoalmente, acho que um servidor simples baseado em SSR é uma solução mais realista
Páginas estáticas não têm esse risco, e a maior parte do tráfego é só leitura
O próprio Jeff parece querer implementar comentários por conta própria na issue
Comparado à época do Drupal, o volume de código ficou muito menor e mais simples
Tenho curiosidade sobre o processo de decisão ao escolher um SSG
Há várias ferramentas importantes como Hugo, Eleventy e Jekyll, e o Hugo em particular quebra compatibilidade com frequência
Para um projeto antigo, acho que ele já deveria garantir estabilidade a essa altura
Isso quebrou o build do meu blog, e a documentação ainda não foi totalmente atualizada
A mudança em si é aceitável, mas o problema é a documentação não acompanhar
Tenho curiosidade sobre como está o Pelican hoje em dia. No ecossistema Python, parece que Hugo e Pelican formam a dupla principal
Às vezes a integração com ActivityPub parece mais atraente do que RSS
Antes eu usava Nikola, mas tinha dependências demais e problemas de inconsistência no build incremental
Gosto do Pelican por manter a simplicidade
Dá a sensação de que a documentação está uns 90% pronta, então faltam detalhes em alguns pontos, mas, se você usar só os recursos básicos, ele é excelente
Há commits todo mês, então o projeto segue vivo
Neste momento estou tentando sair do Hugo para Zola
A configuração e os templates do Zola parecem muito mais intuitivos
Automatizo build e deploy com GitHub Actions
Uso Hugo há 3 anos
O que aprendi é: faça fork do tema e gerencie você mesmo
Evite submódulos e vá atualizando devagar
A parte de comentários ainda parece complicada
Eu também tentei portar um tema de Drupal e desisti
Acho melhor incluir diretamente e sobrescrever só o que for necessário, em vez de usar submódulos
No ano passado comecei um blog com Hugo, mas em 3/4 de 18 posts sofri com erros de build
Fiquei decepcionado com a instabilidade
Em vez de me acostumar ao jeito do Hugo, foi muito mais confortável implementar rapidamente em uma linguagem que eu já conhecia
No passado criei um SSG simples por conta própria, mas recentemente, procurando algo mais estruturado, testei o 11ty
Só que os templates em Liquid eram muito incômodos
Eu queria usar templates baseados em JSX, mas o 11ty dificulta isso
O SSG do NextJS tem muitos recursos, mas é complexo demais e parece exagerado
Também estou considerando criar um SSG customizado sobre um framework como Tempest
Eu também migrei um site baseado em Punch para Eleventy e, se a velocidade de build estiver boa, acho melhor que Hugo
Agora refiz tudo em Astro
Ele é centrado em estático, mas ainda permite usar lógica de backend quando necessário
O NextJS era complexo demais para um site simples