Alleycat: Reconstruí el CMS de mi blog

Hola, soy un inútil.
He reconstruido el CMS de mi blog.
GitHub - haturatu/alleycat: cms & frontend · GitHub

Al final, si iba a construir todo esto, ¿no hubiera sido mejor usar WordPress? Hay una parte de mí que piensa eso.

¿Por qué lo construí?

Mi blog, que originalmente migró de WordPress a LumeCMS alrededor de 2020, tenía las siguientes intenciones de migración:

• WordPress

  • Consume bastante memoria

  • Alojar MySQL solo para un blog personal es excesivo

  • La extensión de funcionalidades depende completamente de plugins

  • CSS y similares tienden a volverse caóticos

  • Es difícil gestionar de forma segura la sección admin sin poder separar los puertos

  • Pegar imágenes directamente era muy fácil

  • Se generan recursos innecesarios, como miniaturas y versiones reducidas de todas las imágenes

• LumeCMS

  • Consume bastante memoria

  • Al ser un CMS SSG, reconstruir todo con cada actualización de un artículo no era eficiente

  • No se pueden subir imágenes directamente copiando y pegando

  • La simplicidad era excelente

  • En realidad, escribir solo en markdown no fue un problema, pero actualizar desde el móvil era bastante difícil en ocasiones.

Así es como fue.

Requisitos

Los requisitos necesarios son los siguientes:

• Posibilidad de separar el CMS por puerto

• Procesamiento de subida de imágenes por copiar y pegar, y generación de enlaces

• Diseño fácil de editar desde el móvil

• Mantener el CSS al mínimo posible para poder entenderlo

  • Es inevitable que aumente con el tiempo

  • Quiero evitar el aumento de CSS de dependencias externas, ya que se vuelve incomprensible.

• Permitir que el frontend sea visible sin JS

  • La construcción estática es esencial para el rendimiento, y quería que fuera amigable para los usuarios de w3m, que yo mismo uso ocasionalmente.

• La tabla de contenidos (TOC) es obligatoria

  • Solo con esto, la legibilidad es completamente diferente.

  • Sin embargo, me preguntaba por qué la TOC de Lume solía empezar desde h2. Que el título no se incluya en la TOC podría ser algo razonable.

  • Pero por alguna razón, Lume solo cubría hasta h3.

    • ¿Quizás para evitar que el diseño se rompa?

• Sería fácil tener un editor Rich Editor y md.

  • Para editar desde el móvil

• Me doy cuenta ahora de la utilidad de las bases de datos.

Sobre la implementación

Personalmente, encontré Pocketbase muy fácil de usar, así que lo adopté. No es necesario implementar una copia de seguridad, ya que se puede guardar un archivo zip de respaldo desde la interfaz de usuario web estándar.

El manejo de información confidencial también es muy fácil, ya que Pocketbase lo implementa de manera adecuada. La base de datos parece ser SQLite.

Además, decidí implementar la compatibilidad multilingüe, algo que quería hacer pero que siempre me resultaba difícil, registrando la Gemini API.

Incluso con Google Translate, hay que ir a la parte superior del navegador y pulsar el botón de traducir, y después de ver varias páginas de documentación, me di cuenta de que era mejor tenerlo integrado. Sin embargo, esto es solo para las páginas de artículos.

Si lo cambiara tanto, ¿el sitio del blog cambiaría demasiado? O más bien, me interesa saber desde la perspectiva de qué país escribe el autor del blog, así que quería que los japoneses se inclinaran hacia una página de About como japoneses, y no sentía la necesidad en otras páginas.

Problema con el número de inodos o E/S de disco

Aunque los SSG tienen problemas similares, la E/S del disco se escanea intensamente cuando aumenta el número de archivos después de la construcción. Dejando de lado la objeción de que los artículos no aumentarán hasta que se agoten los inode, no quiero aumentar las operaciones de lectura/escritura de disco innecesariamente.

En cuanto a esto, los datos públicos después de la construcción no requieren tanta persistencia. Por lo tanto,

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

De esta manera, al exportar por defecto a /tmp, los archivos estáticos construidos se colocan en la RAM para su distribución.

Ubicación de almacenamiento de datos de imagen

Básicamente, quería poder copiar y pegar imágenes desde el editor web y que la exportación en sí misma facilitara la coherencia entre los artículos y los conjuntos de imágenes, por lo que decidí insertar los binarios directamente en Pocketbase.

Hay un punto en el que me pregunto si esto es lo correcto... pero nunca tuve que mirar la carpeta donde se almacenan las imágenes, y es para eliminar la complejidad. Además, se beneficia de la facilidad de verificación en Pocketbase, por lo que lo hice así.

Recursos finales: menos de 500 MiB

Siento que ha quedado bastante bien.

Cuando se está construyendo, se ve como en la imagen de arriba, pero los recursos en espera son aproximadamente estos. Tiende a converger a menos de 150 MiB.

Me alegro de haber podido implementarlo con estos recursos, incluyendo el CMS, y también quería probar por mí mismo hasta dónde podía llevar el diseño del frontend con Codex, así que creo que fue una buena prueba.

Hasta la próxima. Saludos.