Durabilidade

O Chinaski é desenhado para sobreviver às modas , da moda do software, da rotatividade de plataformas, do lock-in de fornecedores, até da própria internet. Esta página explica o que isso significa em termos concretos: URLs duráveis, conteúdo durável e formatos de saída duráveis, e o que os torna assim.

URLs duráveis

Links são promessas. O Chinaski os cumpre assim:

Renomear nunca quebra links. Quando você renomeia uma página ou post publicado , ou muda o prefixo de URL do blog , os redirecionamentos para cada endereço antigo são gerados no próximo rebuild, automaticamente. URLs antigas continuam funcionando enquanto o seu site existir.
Um domínio só é imposto com um redirecionamento embutido: qualquer grafia do seu host que você não escolheu (www ou apex) manda os visitantes para a que você escolheu, preservando a página.
URLs são arquivos. Cada página existe estaticamente como um diretório HTML no disco. Os leitores as alcançam por qualquer servidor web capaz de servir um arquivo , o sistema de conteúdo não precisa estar vivo, nem sequer em execução, para o site funcionar. Não há esquemas de URL específicos de framework para apodrecer.
Traduções e links alternativos permanecem coerentes. Cada idioma tem o seu sitemap, regras de redirecionamento e tags hreflang com referências cruzadas , a descobribilidade sobrevive a redesenhos da estrutura de menus acima dela.

Conteúdo durável

Um arquivo, sem servidores. Todo o conteúdo , páginas, posts, metadados de mídia, contas, histórico de auditoria , vive em um único arquivo de banco de dados SQLite. Fazer backup dele é copiar um arquivo; não há nada a redescobrir ou reconfigurar durante uma restauração. Sem credenciais, sem caminho de rede, sem cerimônia de migração entre lançamentos menores.
O histórico é embutido, não comprado. Cada salvamento tira um snapshot de revisão; cada mutação de conteúdo é registrada em um log de auditoria; envios de formulários e seus metadados são retidos conforme as suas regras de retenção. Restaurar para ontem é uma operação suportada que não exige arqueologia forense.
Backups são verificados, não presumidos. Cada arquivo é testado por fumaça após a criação, e cada execução agendada registra o seu desfecho em um log , sucesso, falha e resultado de verificação por backup.
Rascunhos sobrevivem a travamentos. Edições não salvas vivem no lado do servidor enquanto você trabalha, então fechar uma aba do navegador ou perder uma sessão depois de um longo trecho de escrita não devora a tarde.
A internet nunca é exigida. A instalação pode ser feita a partir de um pacote offline; depois disso, sem telemetria, sem phone-home de licença, sem dependências de CDN. Se a rede desaparecer, o seu site existe no disco e o admin no seu servidor , continuidade planejada, não acidental. Há um modo de implantação "end of the world": o servidor responde HTTP puro para sempre, nada a renovar, nada a expirar.
As dependências são chatas de propósito. Tudo de que o software depende vem na versão estável do sistema operacional, então reescritas maiores de bibliotecas de terceiros não podem vaporizar comportamentos. A lista de dependências é curta por design , nove módulos, mantidos deliberadamente pequenos.
Até a documentação vem com a instância. Os artigos de ajuda visíveis na área de administração são guardados no mesmo banco de dados, então viajam com os seus backups.

Formatos de saída duráveis

A saída publicada do site se prende aos formatos que a web jamais descontinuou:

HTML puro, estilizado de forma genérica, sem runtime obrigatório , o site público tem zero JavaScript em runtime, por construção em vez de por política. Nada para um rastreador se agarrar; nada para quebrar quando um fornecedor terceiro muda os seus termos.
Feeds e arquivos padrão, regenerados a cada build: sitemap.xml, feeds RSS, robots.txt, um arquivo de política de segurança (security.txt) e arquivos de regras de redirecionamento em formatos portáteis que outros servidores conseguem usar.
Dados estruturados (JSON-LD) são escritos direto nas páginas como HTML puro , legíveis por décadas, por mecanismos de busca ou por scripts que você ainda não escreveu.
Extras opcionais offline-first: um service worker e uma página offline fazem parte da saída gerada quando as funcionalidades PWA estão habilitadas.
O servidor de administração em si pode sobreviver sem internet , HTTP puro, sem certificado a renovar, sem serviço externo para falhar.

O que deliberadamente não fazemos

A honestidade sobre os trade-offs faz parte do mesmo princípio:

Não há construtor visual de páginas com arrastar e soltar. O conteúdo do corpo usa um editor de rich text; todo o resto são formulários estruturados. Um construtor visual está no roadmap; não existe hoje.
Não há ecossistema nem marketplace de plugins , sem hooks, sem registros, sem cadeias de código de terceiros que mudam silenciosamente o que o seu site faz no ano que vem.
O banco de dados é SQLite, um arquivo por instância. Um tier multi-tenant com Postgres está no roadmap, não lançado hoje; o caminho de migração ainda não está definido.
Você é dono do servidor, do banco de dados e dos backups. Durabilidade aqui significa responsabilidade sua, não custódia nossa.

A aposta silenciosa por baixo

Por baixo de tudo isso há uma aposta: ferramentas estáveis sobrevivem às espertas. A linguagem em que o sistema é escrito (Perl) não quebrou compatibilidade em décadas de lançamentos menores; o motor SQL (SQLite) trata o seu banco de dados como um arquivo; a saída são arquivos HTML no disco; a interface de administração evita frameworks que reescrevem seus idiomas a cada dois anos. É chato de propósito , um site construído sobre o Chinaski ainda deve render bem daqui a uma década, com manutenção zero, e o conteúdo deve estar exatamente onde você o deixou.