Simplicidad

Chinaski está construido para ser pequeño hoy y seguir siendo comprensible mañana: un par de programas Perl hechos a propósito, un archivo de base de datos SQLite y un servidor web que reparte archivos. Sin service mesh, sin runtime de plugins, sin agitación de frameworks. Esta página recorre las partes, y las omisiones deliberadas, que hacen simple al sistema.

Dos programas, no una flota

El producto completo es:

• El CMS: una aplicación Perl que administra el contenido y te muestra una interfaz de administración en el navegador. Todo lo que sabe vive en un solo archivo de base de datos SQLite.
• El builder: un proceso Perl separado que lee la misma base de datos, renderiza la salida de Template Toolkit y escribe HTML estático al disco. Corre cuando se pide un build (botón del dashboard, webhook, o a mano), nunca como efecto secundario en segundo plano, y cada corrida deja un log.
• El servidor web: un reverse proxy (Caddy en los ejemplos del proyecto) sirve archivos estáticos directamente desde el disco; el proceso del CMS nunca está en la ruta de peticiones públicas.

Así que "un monolito" en espíritu, con una excepción que el README hace explícita: los builds ocurren en su propio proceso, a propósito, porque son operaciones largas con sus propios logs. El builder realiza su swap atómicamente (rename a su lugar), así que un proxy nunca sirve salida a medio escribir.

Una base de datos, un archivo de esquema

Todo el estado (contenido, usuarios, settings, logs) son tablas en un único chinaski.db. No hay ORM, no hay servidor de base de datos, no hay credenciales que administrar. El esquema vive en un solo archivo schema.sql, y un script guardián compara el archivo de esquema contra las migraciones aplicadas a pedido, saliendo visiblemente con código nonzero cuando ambos divergen para que la deriva no pueda esconderse.

Legible por encima de ingenioso

El código es plano por diseño:

• La implementación vive en un número pequeño de archivos, estratificados con comentarios que incluyen referencias al issue tracker, de modo que la historia de un cambio es tan legible como su forma actual.
• Una librería corta de módulos (DB.pm, I18n.pm, Media.pm, Migrations.pm, Util.pm, Webhook.pm y un puñado de módulos de plugins) lleva justo la maquinaria compartida; no hay un framework dentro del framework.
• Donde copias de la lógica llegaron a divergir, el proyecto consolidó en un helper canónico (el helper de apertura de base de datos existe precisamente para que los scripts dejen de fabricar sus propias copias a mano) en lugar de añadir una capa de abstracción que maquille la diferencia.
• Los helpers de línea de comandos del admin son scripts pequeños que siguen todos las mismas convenciones de entorno: los mismos nombres de variables, los mismos defaults.

La visibilidad de la complejidad también es parte de la legibilidad: el builder mismo registra tiempos por fase, y el build guard mide conteos de páginas y enlaces rotos antes de promover nada, no porque el código sea ingenioso, sino porque el sistema te dice lo que hizo.

Pocos puntos de configuración, una forma de despliegue

• Las unidades estándar de systemd usan una plantilla de instancia: una definición sirve cualquier cantidad de instancias (chinaski@1, chinaski@prod, …). Todo lo demás de un despliegue son dos env vars más una línea o dos de reverse proxy.
• Donde sí existe complejidad transicional, está nombrada, acotada y programada para eliminación; la migración del skin del admin es el ejemplo trabajado: un sistema de clases objetivo, una capa de compatibilidad hacia atrás explícitamente para no extender, y seguimiento por archivo hasta que los nombres heredados desaparezcan.
• Layout de directorios plano: el archivo de la app, el esquema, el archivo de dependencias, el builder, las plantillas del admin, los árboles de salida por idioma, los assets públicos. Lo que hace cada parte se ve desde su nombre de archivo.

Lo que esta simplicidad compra, y cuesta

• Operación: dos servicios systemd y un timer, árboles de salida transparentes que puedes sincronizar con rsync, respaldos que son una copia de archivo, sin gestor de paquetes propio.
• Los cambios permanecen legibles: el codebase es abundante en comentarios con referencias a issues, estructurado de modo que una corrección no requiera arqueología.
• El costo lo declara con honestidad el proyecto: sin arquitectura de plugins, sin registro de plugins, sin marketplace de temas; lo que obtendrías de eso tiene que ser o un cambio de código o no hacerse.

La regla general

La respuesta por defecto de Chinaski a "¿deberíamos añadir esto?" es "¿seguirá teniendo sentido para alguien que lo lea en frío a las 2 de la mañana?", un monolito por proceso, pocas piezas móviles, y código legible le gana a las abstracciones ingeniosas.