Una aplicación web moderna en C
Construir una aplicación web “moderna” en C puro usando CGI, SQLite y el httpd de OpenBSD reaviva el entusiasmo por las pilas minimalistas y, al mismo tiempo, los debates de siempre sobre la seguridad de C y su idoneidad para servicios expuestos en Internet. Muchos comentaristas valoran la simplicidad, la predictibilidad y la huella mínima de dependencias de un único binario estático invocado por petición, especialmente frente a configuraciones multinivel con nginx, servidores de aplicaciones y grandes frameworks. Los críticos responden que el manejo de cadenas, la concurrencia y la seguridad de memoria hacen que C sea una mala elección frente a Go, Rust o PHP/FastCGI, y argumentan que cualquier ventaja de rendimiento o arquitectura debe sopesarse frente a los riesgos de seguridad y la realidad de la observabilidad y el mantenimiento modernos.
Elección de C y la pila BCHS
- A muchos les intriga construir una aplicación web “moderna” en C puro con OpenBSD httpd y SQLite (BCHS).
- Motivaciones inferidas: dependencias mínimas, comportamiento predecible, encaje estrecho con pledge/unveil de OpenBSD y la sensación de que C “cabe en la cabeza”.
- Algunos cuestionan por qué se eligió C en lugar de C++, Rust, Go o PHP, argumentando que otros lenguajes podrían ofrecer una simplicidad similar con más seguridad y herramientas.
CGI, modelo de procesos y rendimiento
- Diseño central: CGI, un proceso nuevo por petición. Los defensores aprecian el aislamiento, el despliegue trivial (sustituir un binario) y la ausencia de servidores de aplicaciones complejos.
- Los críticos llaman a CGI una “medida a medias” e “ineficiente”, señalando el coste de creación de procesos y la falta de estado compartido; sugieren en su lugar FastCGI, módulos en proceso o servidores HTTP personalizados.
- Otros responden que los kernels modernos hacen que
forksea lo bastante barato para tráfico bajo/medio, y comparan este modelo con las funciones “serverless” de hoy.
SQLite y concurrencia
- Se plantean dudas sobre varias peticiones concurrentes accediendo a un único archivo SQLite.
- Respuestas: activar el modo WAL permite muchos lectores concurrentes con un solo escritor; el bloqueo de archivos gestiona la concurrencia entre procesos. Las escrituras siguen serializándose, pero son rápidas al no haber saltos de red.
Manejo de cadenas y ergonomía de C
- Varios señalan que generar HTML/CSS en C es tolerable; analizar y tratar cadenas en general son las partes dolorosas.
- Algunos lo mitigan con constructores/vistas de cadenas personalizados y buffers de tamaño fijo para evitar asignaciones.
Seguridad y elecciones de lenguaje
- Hay un fuerte desacuerdo sobre exponer nuevo código en C a Internet.
- Críticos: la inseguridad de memoria de C conduce a RCE recurrentes; existen opciones más seguras (Rust, “C-style C++”).
- Defensores: gran parte de la infraestructura subyacente (kernels, servidores web, bases de datos) ya es C/C++; un diseño cuidadoso, el endurecimiento de OpenBSD y un código pequeño y auditable pueden ser seguros.
- Se elogia Rust por su seguridad de memoria, pero se critica su pesado grafo de dependencias y el riesgo de la “cadena de suministro”; C se ve como un intercambio entre seguridad de memoria y superficies de dependencia más simples y pequeñas.
Simplicidad frente a pilas modernas
- Muchos expresan nostalgia por CGI y los primeros días de PHP/Perl, y cansancio con las pilas actuales de múltiples capas (nginx → servidor de aplicaciones → framework → ORM, etc.).
- Algunos sostienen que las capas modernas añaden funciones necesarias (observabilidad, escalado, limitación de tasa), mientras que otros dicen que eso es excesivo para sitios pequeños y herramientas internas.
Frontend, UX y preocupaciones por texto generado por IA
- Varios comentaristas consideran que el diseño del sitio mostrado es difícil de leer y tiene poco contraste.
- Algunos sospechan que partes de la entrada del blog están escritas por IA, aunque otros lo discuten y señalan que los detectores de IA no son fiables.