Um Aplicativo Web Moderno em C
Construir um aplicativo web “moderno” em C puro usando CGI, SQLite e o httpd do OpenBSD reacende o entusiasmo por stacks minimalistas, ao mesmo tempo em que revive debates de longa data sobre a segurança do C e sua adequação para serviços expostos à internet. Muitos comentaristas gostam da simplicidade, da previsibilidade e da superfície mínima de dependências de um único binário estático invocado por requisição, especialmente em comparação com configurações multicamadas envolvendo nginx, servidores de aplicação e frameworks grandes. Críticos contrapõem que manipulação de strings, concorrência e segurança de memória tornam o C uma escolha ruim frente a Go, Rust ou PHP/FastCGI, e argumentam que quaisquer ganhos de desempenho ou arquitetura devem ser ponderados contra os riscos de segurança e as realidades da observabilidade e manutenção modernas.
Escolha de C e da stack BCHS
- Muitos se sentem intrigados com a ideia de construir um aplicativo web “moderno” em C puro com o httpd do OpenBSD e SQLite (BCHS).
- Motivações inferidas: dependências mínimas, comportamento previsível, encaixe próximo com
pledge/unveildo OpenBSD e a sensação de que C “cabe na cabeça”. - Alguns questionam por que C foi escolhido em vez de C++, Rust, Go ou PHP, argumentando que outras linguagens poderiam oferecer simplicidade semelhante com mais segurança e ferramentas.
CGI, modelo de processo e desempenho
- Design central: CGI, um processo novo por requisição. Os defensores gostam do isolamento, da implantação trivial (substituir um único binário) e da ausência de servidores de aplicação complexos.
- Críticos chamam CGI de um “meio-termo” e “ineficiente”, observando o custo de criação de processos e a falta de estado compartilhado; eles sugerem FastCGI, módulos em processo ou servidores HTTP personalizados em vez disso.
- Outros respondem que kernels modernos tornam
forkbarato o suficiente para tráfego baixo/médio e comparam esse modelo às funções “serverless” de hoje.
SQLite e concorrência
- Surgem প্রশ্নões sobre múltiplas requisições concorrentes atingindo um único arquivo SQLite.
- Respostas: habilitar o modo WAL permite muitos leitores concorrentes com um único escritor; o bloqueio de arquivo lida com a concorrência entre processos. As gravações ainda são serializadas, mas são rápidas sem idas e vindas pela rede.
Manipulação de strings e ergonomia em C
- Vários observam que gerar HTML/CSS em C é tolerável; analisar e lidar com strings em geral é a parte dolorosa.
- Alguns contornam isso com construtores/views de strings personalizados e buffers de tamanho fixo para evitar alocações.
Segurança e escolhas de linguagem
- Há forte discordância sobre expor novo código em C à internet.
- Críticos: a insegurança de memória do C leva a RCEs recorrentes; escolhas mais seguras (Rust, “C++ com estilo C”) existem.
- Defensores: a maior parte da infraestrutura subjacente (kernels, servidores web, bancos de dados) já é C/C++; design cuidadoso, hardening do OpenBSD e código pequeno e auditável podem ser seguros.
- Rust é elogiado pela segurança de memória, mas criticado por grafos de dependências pesados e risco de “cadeia de suprimentos”; C é visto como uma troca da segurança de memória por superfícies de dependência mais simples e menores.
Simplicidade vs stacks modernas
- Muitos expressam nostalgia pelo CGI e pelos primeiros dias de PHP/Perl e cansaço com as pilhas multicamadas de hoje (
nginx→ servidor de aplicação → framework → ORM, etc.). - Alguns argumentam que camadas modernas adicionam recursos necessários (observabilidade, escalabilidade, limitação de taxa), enquanto outros dizem que isso é exagero para sites pequenos e ferramentas internas.
Frontend, UX e preocupações com escrita por IA
- Vários კომენტaristas acham o design do site mostrado difícil de ler e com baixo contraste.
- Vários suspeitam que partes da postagem do blog foram escritas por IA, embora outros discordem e observem que detectores de IA não são confiáveis.