Alleycat: Refiz o CMS do meu blog

Olá, sou um incompetente.
Tentei refazer o CMS do meu blog.
GitHub - haturatu/alleycat: cms & frontend · GitHub

No final das contas, se fosse para construir tudo isso, talvez tivesse sido melhor usar o WordPress, não é?

Por que eu o construí

Meu blog, que originalmente migrou do WordPress para o LumeCMS por volta de 2020, tinha as seguintes intenções de migração:

• WordPress

  • Consome bastante memória

  • Hospedar um MySQL apenas para um blog pessoal é excessivo

  • A extensão de funcionalidades depende totalmente de plugins

  • CSS e outros tendem a ficar caóticos

  • É difícil gerenciar com segurança a área admin sem poder separar as portas

  • Era muito fácil colar imagens diretamente

  • Todas as imagens geram miniaturas e versões reduzidas, criando recursos desnecessários

• LumeCMS

  • Consome bastante memória

  • Como é um CMS SSG, reconstruir tudo a cada atualização de artigo não era ecológico

  • Não é possível fazer upload de imagens diretamente por copiar e colar

  • A simplicidade era ótima

  • Na verdade, escrever apenas em markdown não era um problema, mas atualizar do smartphone era bastante difícil em algumas ocasiões

É algo como o que foi mencionado acima.

Requisitos

Os requisitos necessários são os seguintes:

• Capacidade de separar o próprio CMS por porta

• Processamento de upload de imagem por copiar e colar, e geração de links

• Design fácil de editar mesmo em smartphones

• Manter o CSS no mínimo possível, desde que seja compreensível

  • É inevitável que acabe aumentando

  • Quero evitar ao máximo o aumento de CSS de dependência externa, pois fica muito confuso

• Permitir que o frontend seja visualizado sem JS

  • Do ponto de vista de desempenho, o Static Build é essencial, e eu queria que fosse amigável para usuários de w3m, que eu ainda uso ocasionalmente.

• TOC é essencial

  • Apenas com isso, a legibilidade é completamente diferente

  • No entanto, eu me perguntei por que o TOC do Lume começava com h2 antes? Mas talvez faça sentido que o título equivalente não seja incluído no TOC?

  • Mas por alguma razão, o Lume só abrangia até h3?

    • Talvez porque o design se desfaça facilmente?

• Seria fácil ter um Rich Editor e md

  • Para edição via smartphone

• Perceber agora a utilidade de um DB

Sobre a implementação

Pessoalmente, achei o Pocketbase muito fácil de usar, então o adotei. Não é necessário implementar o backup de dados, pois é possível salvar o arquivo zip de backup diretamente da UI web padrão.

O tratamento de informações confidenciais também é muito fácil, pois o Pocketbase já o implementa de forma adequada. O DB parece ser SQLite.

Além disso, decidi implementar o suporte multilíngue, algo que eu queria fazer, mas que sempre foi um grande obstáculo, registrando a Gemini API.

Mesmo com o Google Tradutor, é preciso ir até o topo do navegador e clicar no botão de tradução, e eu realmente pensei que seria melhor ter isso integrado depois de ver várias páginas de documentação. No entanto, isso é apenas para as páginas de artigos.

Se eu mudasse tanto assim, o site do blog mudaria? Ou melhor, como me importo com a perspectiva do autor do blog, de que país ele está escrevendo, eu queria que os japoneses tivessem uma página 'Sobre' como japoneses, e não senti a necessidade em outras páginas.

Problemas com o número de inodes ou I/O de disco

Mesmo com SSG, enfrentamos problemas semelhantes; o I/O de disco é intensamente varrido quando o número de arquivos pós-compilação aumenta. Deixando de lado a observação de que os artigos não aumentarão até que os inodes se esgotem, não quero aumentar o rw de disco desnecessariamente.

Nesse sentido, os dados públicos pós-compilação não exigem tanta persistência. Por isso,

$ rg tmp
backend/ssr/config.go
13:     staticExportDir  = getEnv("STATIC_EXPORT_DIR", "/tmp/alleycat-static")

Dessa forma, ao exportar para /tmp por padrão, os arquivos estáticos pós-compilação são colocados na RAM e entregues.

Local de armazenamento de dados de imagem

Basicamente, eu queria poder copiar e colar imagens do editor web e fazer upload, e também garantir que a exportação em si mantivesse a integridade entre artigos e conjuntos de imagens. Por isso, decidi inserir os binários diretamente no Pocketbase.

Pode-se questionar essa abordagem, mas eu nunca precisei olhar a pasta onde as imagens estavam armazenadas, e é para eliminar a complexidade. Além disso, há o benefício de ser fácil de verificar no Pocketbase, então optei por isso.

Recursos finais: Menos de 500MiB

Sinto que ficou bastante bom.

Ao construir, fica como na imagem acima, mas os recursos em espera são aproximadamente isso. Tende a convergir para menos de 150MiB.

Fico feliz por ter conseguido implementar isso com esses recursos, incluindo o CMS. Também queria experimentar por mim mesmo até que ponto eu poderia aprimorar o design do frontend com Codex, então acho que foi um bom teste.

Até a próxima. Agradeço a atenção.