This article will be published in english at a later date

Conteúdo

1. Introdução
2. Requisitos arquiteturais
3. Escolhendo um gerador
4. Outras escolhas
5. Melhorias futuras
6. Os finalmentes

Introdução

Eu havia escrito uma introdução que envolvia algumas piadas e um ditado¹ mas decidi ir direto ao ponto, começando pelos…

Requisitos arquiteturais

1. Site estático

   • Meu site não deve passar de um conjunto de páginas HTML estaticamente geradas, com foco na experiência de usuário;
   • Sites inutilizáveis sem JavaScript ativado têm casos de uso específicos, e blog não é um deles²;
   • Não, eu não quero pagar um servidor só pra usar SSR³.

2. Experiência do Desenvolvedor (DX)

   • Integrações com IDEs, builds rápidos, type checks, etc.

3. Suporte a MDX

   • Extensão de Markdown que permite o uso de JSX;
   • Algumas implementações permitem até o uso de Frontmatter⁴;
   • Sintaxe bonita, formosa e cheirosa².

4. Facilidade de migração

   • Conteúdo deve ser separado da implementação do website, a fim de facilitar migrações futuras.

Escolhendo um gerador

ML;NL⁵: Astro é um EXCELENTE gerador. Recomendo fortemente.

NextJS também, mas seu ponto forte é a criação de aplicações web, o que não é meu caso de uso. Vercel+NextJS é uma combinação tão boa que eu migrarei no futuro, caso necessário.

Existe uma infinidade de frameworks de geração de sites estáticos, mas três chamaram minha atenção: Jekyll, NextJS e Astro — focaremos nos dois últimos.

NextJS

Dos mesmos criadores de Vercel, é um framework para aplicações web com React do back-end ao front-end. Apesar de ser uma boa ferramenta, muitas de suas funcionalidades seriam inutilizadas em ioxua.com — podemos encontrar uma alternativa melhor.⁶

Astro

Astro é um framework web focado em desempenho⁷. Para isso, utiliza o conceito de “Componentes Isolados”⁸, emitindo 0kb de código JS por padrão, mas opcionalmente permitindo o uso de qualquer framework front-end (leia mais aqui).

Mas como esse framework se adequa aos meus requisitos?

1. Site estático

   • A filosofia de 0 código JS em tempo de execução se adequa perfeitamente à minha expectativa de desempenho;
   • Adicionando um pouco de degradação graciosa, tenho um site totalmente utilizável sem JS :)
   • Um relatório vale mais que mil palavras.

2. Experiência de Desenvolvedor

   • Astro é todo tipado com TypeScript, o build inicial leva ~400ms e o framework suporta Hot Reload fora da caixa \o/

3. Suporte a MDX

   • @astrojs/mdx;
   • O Frontmatter⁴ dos arquivos também é tipado graças ao uso de Coleções de Conteúdo.

4. Facilidade de migração

   • Infelizmente aqui o framework peca um pouco, a definição de componentes reutilizáveis usa uma sintaxe própria;
   • Felizmente, arquivos .astro podem ser facilmente convertidos para componentes React, mas a migração para outros frameworks exigirá algum trabalho.

Tudo isso resulta em:

Nada mal, hein?

Outras escolhas

Estrutura de pastas

Este site é um monorrepositório, até o momento com um só projeto⁹:

.
├── docs (1)
├── patches (2)
└── website (3)
    ├── assets (4)
    ├── build (5)
    ├── public (6)
    └── src
        ├── components (7)
        ├── content (8)
        │   ├── blog
        │   │   ├── br
        │   │   └── en
        │   └── sections
        │       ├── br
        │       └── en
        ├── i18n (9)
        ├── layouts (10)
        ├── pages (11)
        │   └── [lang]
        │       └── b
        │           ├── _page.astro
        │           └── [...slug].astro
        └── utils (12)

1. Informações sobre o conteúdo do post e documentação de processos internos;
2. Pasta de alterações do patch-package, usei para corrigir um bug interno do Husky;
3. Projeto Astro do site em que você se encontra;
4. Imagens, localizadas aqui por serem pré-processadas com @astrojs/image;
5. Scripts utilitários para configuração e build do projeto;
6. Arquivos servidos sem alteração, como robots.txt e favicon.svg
7. Componentes Astro reutilizáveis;
8. O conteúdo do site, organizado por categoria (atualmente posts do blog e seções traduzíveis do site¹⁰);
9. Traduções usadas para textos curtos¹⁰;
10. Layouts de página reutilizáveis;
11. Páginas específicas do site como a index e 404;

Estilização

Estou usando Tailwind.css simplesmente por querer aprender um novo framework CSS. O fato de ter crescido consistentemente em uso desde 2019 e ser considerado o framework CSS com maior retenção de desenvolvedores em 2022 me deu mais alguns motivos para testar.

Minha experiência com Tailwind ainda é pouca, mas até o momento fiz algumas observações, sem ordem específica:

• Prototipação é muito simples e eficiente, graças ao paradigma utility-first;
• Este plugin é excelente, economizou-me muito tempo estilizando texto;
• Alguns elementos acabam com muitas classes CSS, talvez algo como CSS Mangle resolva o problema, reduzindo uns bytes dos arquivos finais.

Melhorias futuras

• Terraform

  • Grande parte da minha configuração de infraestrutura foi feita manualmente no Vercel. Não gosto disso, por isso desejo migrar;
  • Eu provavelmente quebrarei a configuração por um tempo, mas esse será o próximo passo!

• Github Actions

  • No mesmo espírito do ponto anterior, todo o pipeline de CI/CD atual é automaticamente implementado pelo Vercel. Nada de testes automatizados e todos os commits enviados para o repositório geram versão do site;
  • Infelizmente o bot do Vercel é muito bom e não funciona se eu alterar o pipeline. Então por hora não alterarei.

• Alguma coisa serverless

  • Preciso só de um caso de uso ;)

Os finalmentes

E foi essa a arquitetura que escolhi para meu site, adicionadas algumas escolhas estilísticas. Não é a estrutura perfeita para blogs pessoais mas acho que é um bom primeiro passo: um MVP, de certa forma.

Este blog ainda vai sofrer muitas mudanças que, quando forem suficientes, serão listadas em um próximo post. Feedback é apreciado :)

o/

Notas de rodapé