Ir para o conteúdo
CarlosDiário de obra

Como este blog foi feito: Astro, Markdown e Git como banco de dados

Sem CMS tradicional, sem banco de dados, sem servidor rodando 24h. Registro de como montei esse diário técnico e por que cada peça da stack existe por um motivo.

Toda entrada aqui é sobre algo que eu construí. Fazia sentido que o próprio blog seguisse a mesma regra: registrar o que funcionou, o que quebrou, e por quê.

O porquê de existir

Eu queria um lugar pra registrar decisão técnica com o mesmo peso que registro código: com data, com contexto, com o que doeu. Não um portfólio polido, um diário de obra — cada post amarrado a um projeto de verdade, com ficha técnica, stack e link pra demo quando existe.

A decisão que definiu o resto: sem banco de dados

O rodapé do site diz “Sem banco de dados. Sem servidor. Só Git.” — e é literal. Uso o Astro com content collections: cada post é um arquivo .md dentro de src/data/posts/, com frontmatter tipado (título, resumo, data, projeto, stack, situação) validado por schema no build. Não existe API, não existe tabela, não existe processo rodando esperando requisição. O git push É o deploy.

Isso significa que o “banco de dados” do blog é literalmente o histórico do repositório. Todo post, toda edição, toda imagem — tudo versionado, tudo com histórico, tudo reversível com git log.

Escrever sem abrir o editor de código

Nem sempre quero abrir o VS Code pra escrever um parágrafo. Pra isso subi o Sveltia CMS em /admin — um painel estático que fala direto com a API do GitHub pelo navegador, sem servidor intermediário. Cada post publicado ou editado pelo painel vira um commit na branch principal. Rascunho fica versionado, mas some da home e do RSS até eu tirar o rascunho: true.

O que fui adicionando no caminho

A base ficou pronta rápido; o resto foi ajuste fino, testado de verdade no navegador a cada mudança:

  • Imagens que ocupam a largura do texto, com a liberdade de colocar duas ou três juntas — nesse caso elas dividem o espaço e encolhem pra caber, sem precisar de nenhum componente especial, só escrever os ![]() sem linha em branco entre eles.
  • Zoom em imagem com um clique, usando <dialog> nativo do navegador em vez de biblioteca externa.
  • Embed de vídeo do YouTube e Instagram, horizontal ou vertical, colando um bloco de HTML direto no Markdown.
  • Busca por título ou projeto, decidida a mostrar resultado só quando eu realmente digito algo — nada de lista cheia poluindo a tela.
  • Pasta de mídia por post (media/<slug>/), depois que excluir um post antigo pelo painel arrastou junto a imagem de capa de outro que eu tinha acabado de publicar. Aprendi isso na marra.

O que eu tirei disso

A parte chata de manter um blog nunca foi escrever — foi manter infraestrutura que eu não precisava. Tirando o banco de dados e o servidor da equação, sobrou só o que importa: o texto e o histórico dele no Git. Cada função nova que eu queria acabava sendo resolvida com HTML/CSS simples e uma pitada de JavaScript, sem puxar dependência pra tudo.

Se esse post existe fixado no topo é porque ele é o mapa: qualquer registro novo daqui pra frente herda essa mesma base.