Simplicidade

O Chinaski é construído para ser pequeno hoje e ainda compreensível amanhã: alguns programas Perl feitos sob medida, um arquivo de banco de dados SQLite e um servidor web que entrega arquivos. Sem service mesh, sem runtime de plugins, sem turbulência de framework. Esta página percorre as partes , e as omissões deliberadas , que tornam o sistema simples.

Dois programas, não uma frota

O produto inteiro é:

O CMS , uma aplicação Perl que gerencia o conteúdo e lhe mostra uma interface de administração no navegador. Tudo o que ela sabe vive em um único arquivo de banco de dados SQLite.
O builder , um processo Perl separado que lê o mesmo banco de dados, renderiza a saída do Template Toolkit e escreve HTML estático no disco. Ele roda quando um build é pedido (botão no painel, webhook ou à mão), nunca como efeito colateral em segundo plano, e cada execução deixa um log.
O servidor web , um reverse proxy (Caddy nos exemplos do projeto) serve os arquivos estáticos direto do disco; o processo do CMS nunca está no caminho público das requisições.

Então, "um monólito" no espírito, com uma exceção que o README deixa explícita: os builds acontecem no próprio processo, de propósito, porque são operações longas com logs próprios. O builder faz a sua troca atomicamente (rename para o lugar), de modo que um proxy nunca serve saída escrita pela metade.

Um banco de dados, um arquivo de schema

Todo o estado , conteúdo, usuários, configurações, logs , são tabelas em um único chinaski.db. Não há ORM, não há servidor de banco de dados, não há credenciais para gerenciar. O schema vive em um único arquivo schema.sql, e um script de guarda compara o arquivo de schema com as migrações aplicadas sob demanda, saindo visivelmente com código diferente de zero quando os dois divergem, para que a divergência não possa se esconder.

Legibilidade acima da esperteza

O código é simples por design:

A implementação vive em um pequeno número de arquivos, em camadas, com comentários que incluem referências ao issue tracker, de modo que a história de uma mudança é tão legível quanto a sua forma atual.
Uma biblioteca curta de módulos (DB.pm, I18n.pm, Media.pm, Migrations.pm, Util.pm, Webhook.pm e um punhado de módulos de plugin) carrega apenas a maquinaria compartilhada; não há um framework dentro do framework.
Onde cópias de lógica um dia divergiram, o projeto consolidou em um helper canônico (o helper de abertura de banco de dados existe precisamente para que os scripts parem de improvisar as suas próprias cópias) em vez de adicionar uma camada de abstração para encobrir a diferença.
Os helpers de linha de comando do admin são scripts pequenos, todos seguindo as mesmas convenções de ambiente , mesmos nomes de variáveis, mesmos padrões.

Visibilidade da complexidade também faz parte da legibilidade: o próprio builder registra tempos por fase, e o guardião do build mede contagens de páginas e links quebrados antes de promover qualquer coisa , não porque o código é esperto, mas porque o sistema conta o que fez.

Poucos pontos de configuração, um formato de implantação

As units systemd padrão usam um template de instância: uma definição serve qualquer número de instâncias (chinaski@1, chinaski@prod, …). Todo o resto de uma implantação são duas variáveis de ambiente mais uma linha ou duas de reverse proxy.
Onde complexidade de transição existe, ela é nomeada, limitada e agendada para deleção , a migração de skin do admin é o exemplo trabalhado: um sistema de classes-alvo, uma camada de compatibilidade retroativa explicitamente para não ser estendida, e rastreamento por arquivo até os nomes legados acabarem.
Layout de diretórios plano: o arquivo da aplicação, o schema, o arquivo de dependências, o builder, os templates do admin, as árvores de saída por idioma, os assets públicos. O que cada parte faz é visível pelo nome do arquivo.

O que essa simplicidade compra , e custa

Operação: dois serviços systemd e um timer, árvores de saída transparentes que você pode rsync, backups que são uma cópia de arquivo, sem gerenciador de pacotes próprio.
As mudanças permanecem legíveis: a base de código é rica em comentários com referências a issues, estruturada para que uma correção não exija arqueologia.
O custo é declarado com honestidade pelo projeto: sem arquitetura de plugins, sem registro de plugins, sem marketplace de temas , o que quer que você obteria com isso precisa ser uma mudança de código ou não ser feito.

A regra de bolso

A resposta padrão do Chinaski a "deveríamos adicionar isto?" é "isso ainda fará sentido para alguém lendo-o de cara às 2 da manhã?" , um monólito por processo, poucas peças móveis, e código legível vence abstrações espertas.