Construir um site de diretório parece trivial até você se ver configurando bancos de dados, camadas de cache e frameworks front-end reativos apenas para exibir o que é, essencialmente, um índice curado. Recentemente, construí o Social Tools List, um site para comparar softwares de redes sociais. Meu objetivo era colocá-lo online rapidamente, mantê-lo rápido e evitar a manutenção de infraestrutura para um conteúdo que só muda quando adiciono ou atualizo uma ferramenta. Optei por uma stack static-first: Astro para geração do site, TypeScript para dados estruturados e Cloudflare Workers para implantação. O resultado é um site que carrega instantaneamente, custa quase nada para hospedar e não exige administração de banco de dados.

Por que o Static-First faz sentido para um diretório

Muitos aplicativos web utilizam por padrão a renderização no servidor ou arquiteturas de página única (SPA) porque parecem escolhas seguras e modernas. Mas nem todo site recebe entradas dinâmicas de usuários em cada requisição. O Social Tools List é um recurso com alta carga de leitura. Os dados de comparação mudam quando eu envio uma atualização, não quando um visitante atualiza a página. Renderizar o HTML antecipadamente elimina a necessidade de consultas ao banco de dados na edge, compilação de templates em tempo real ou o overhead de hidratação no navegador. Eu gero o site no momento do build, implanto os arquivos estáticos e deixo um worker leve lidar com o wrapper. Isso mantém os tempos de resposta baixos e elimina toda uma classe de falhas em tempo de execução.

Armazene dados em TypeScript, não em um banco de dados

Eu não utilizo um banco de dados. Cada ferramenta no diretório é definida como um objeto TypeScript com um slug, nome, domínio e um array de workflows suportados. Uma entrada típica se parece com isto:

{
  slug: 'buffer',
  name: 'Buffer',
  domain: 'buffer.com',
  workflows: ['scheduling', 'analytics']
}

Armazenar dados na mesma linguagem que constrói o site traz dois benefícios imediatos. Primeiro, os pull requests tornam-se revisões de conteúdo. Quando adiciono uma ferramenta, o diff mostra os campos e valores exatos, e um colega de equipe pode identificar um erro de digitação ou um domínio incorreto sem precisar aprender uma interface de CMS. Segundo, o compilador do TypeScript impõe o formato de cada registro. Se eu esquecer de incluir um slug ou errar a grafia de uma chave de workflow, o build falha antes que os dados incorretos cheguem a uma página.

Um banco de dados introduziria migrações, connection strings, estratégias de cache e rotinas de backup. Para um diretório com algumas centenas de entradas que eu mantenho manualmente, esse overhead é um puro entrave. Dados estáticos em módulos TypeScript são a escolha correta e mais barata para este modelo. A parte do "correto" é importante. Não se trata apenas de economizar dinheiro; trata-se de remover camadas de abstração que resolvem problemas que eu não tenho.

Deixe o Astro cuidar do roteamento e da renderização

O Astro gera uma página HTML por ferramenta a partir de uma única rota dinâmica. Eu defino um componente de layout, e o Astro gera automaticamente os metadados, cabeçalhos e dados estruturados para cada entrada. Como o mesmo conjunto de dados alimenta o índice principal, os hubs de categorias de workflow e as páginas de detalhes individuais, não há chance de um card na página inicial mostrar uma descrição diferente da própria página de detalhes. Em configurações tradicionais de CMS, é comum ver divergências: a API retorna uma versão, o cache outra e a renderização no lado do cliente uma terceira. A geração estática a partir de uma única fonte de verdade evita isso.

A arquitetura de ilhas (islands architecture) do Astro também facilita a adição de pequenos elementos interativos sem "envenenar" a página inteira com JavaScript. O site é entregue como HTML estático, e apenas o script de filtragem hidrata seu canto específico do DOM. Não há um runtime de framework envolvendo todo o documento. O Astro também trata os metadados da página como uma preocupação de primeira classe. Cada página de ferramenta recebe sua própria tag de título e meta descrição derivadas diretamente do registro TypeScript, portanto, não preciso de um plugin separado ou de uma biblioteca de gerenciamento de head.

Filtragem sem um framework

Busca e filtragem muitas vezes levam os desenvolvedores a instalar React, Vue ou uma biblioteca pesada de gerenciamento de estado. Eu resisti a isso. O Astro renderiza a lista completa como HTML puro no servidor. Um pequeno script em JavaScript vanilla, com menos de um quilobyte, roda no navegador e alterna a propriedade display dos itens da lista com base em uma tag de workflow ou uma correspondência de texto.

Servir a marcação completa parece ineficiente se você tem experiência baseada em APIs. Mas considere o overhead de uma abordagem dinâmica típica. O navegador baixa um bundle de JavaScript, hidrata uma árvore de componentes, chama um endpoint, espera pelo JSON e então renderiza as linhas. Para um diretório que lista menos de cem ferramentas, esse ritual é mais lento e menos confiável do que ocultar divs que já estão no documento. Meu script anexa event listeners aos botões de filtro, lê um atributo data-workflow em cada linha e define os itens que não correspondem como ocultos. A operação leva milissegundos.

Como a lista está presente no HTML inicial, o site é utilizável sem JavaScript. Crawlers de mecanismos de busca veem cada link e cada descrição. Usuários em redes lentas ou com bloqueadores de scripts ainda recebem o diretório completo. A filtragem é um aprimoramento, não uma barreira.

Sitemaps e Robots como Código

Sitemaps e robots.txt não são meros complementos escritos à mão. Eles são rotas Astro que consomem o mesmo conjunto de dados e helpers de URL que