Un producto web comercial en C que funciona con CGI
A Modern Web App in C
Corey Prophitt cuenta cómo construyó marketyour.games, un producto comercial con cuentas de usuario, dashboard de búsqueda, pagos con Stripe y correos con Postmark, usando el stack BCHS: OpenBSD, C, httpd y SQLite. Sin frameworks, sin contenedores, sin JavaScript. Un solo binario estático, un archivo SQLite y tres dependencias. Cada petición lanza un proceso CGI. Despliegue sin downtime, cadena de suministro mínima y toda la aplicación en la cabeza.
CGI is serverless, minus the vendor (and surprise bills).
- dorongrinstein
Muchas herramientas pueden lograr lo mismo. Puedo escribir una nota en lápiz, bolígrafo, crayón, etc. Te contaré un secreto, pero no se lo digas a nadie: también puedes escribirla en ensamblador.
- ramses0
Mi dato curioso favorito es que busybox tiene soporte cgi-bin integrado (y `rclone serve webdav` parece una omisión no mencionarlo también). `https://elixir.bootlin.com/busybox/1.37.0/source/networking/...`
Todo lo que menciona el post es 100% cierto y bien razonado, especialmente con la inclusión de pledge/chroot/etc. para reducir privilegios.
Hay dos mecanismos de despliegue diametralmente opuestos:
1) apilar torres de porquería una encima de otra hasta que estás ejecutando un simple `echo "hello world"` sobre un contenedor docker dentro de una vm en un servidor proxmox como parte de un clúster k8s bajo un hipervisor corriendo en cómputo remoto...
2) simplemente ejecutar `bash -c 'echo "hello world"'` y ponerle CGI al frente (sin estado, binario único, bla bla bla...)
Echa un vistazo a https://github.com/Domain/bash.cgi ... no es que esté sugiriendo que 'bash sobre busybox usando cgi-bin' sea la "arquitectura adecuada", más bien intenta ilustrar que la cantidad de código que te impide ser casi verdaderamente "sin framework" es mínima y fácil de razonar.
Para algunas de las herramientas internas que estoy haciendo para el trabajo, he tendido hacia:
some-cmd [--json|--markdown] ...yet-more-args...
Cuando usas el proceso y el entorno de shell en sí como un repl, empiezas a tender hacia que `[--cgi-bin]` "simplemente" sea otro tipo de salida, y la capacidad (¡no, la previsión!) de asegurar que tus comandos sean independientes, reproducibles y solo dependan de sus argumentos de entrada te lleva directamente a poder ejecutarse tanto en entornos "hostiles" ( […]
- OleksandrC
Para las personas que encuentran interés en aplicaciones web raras, he estado trabajando en un proyecto de juego, en C++, donde el cliente se compila a WebAssembly con Emscripten, y el servidor de aplicaciones también está implementado en C++ (detrás de nginx).
Esto también es de la era pre-IA. El juego es tipo Civ. Motor personalizado desde cero (incluyendo tanto las cosas 3D como todo el manejo web también).
Echa un vistazo: https://statebuilder.com/
- assimpleaspossi
Comencé una empresa de desarrollo web hace 22 años después de desarrollar un sistema de pedidos de menú en línea para un restaurante que era mío. Yo, y luego nosotros, hicimos prácticamente lo mismo que se menciona en la publicación, pero usábamos fastcgi. Empecé con C porque sabía C. Ese era mi trabajo real. Funcionaba tan bien que la franquicia me compró el software, y luego lo degradaron a todas las cosas de Microsoft y tuvieron problemas tras problemas a partir de entonces. Esa es otra historia.
Seguí haciendo sitios para otros lugares que necesitaban pedidos en línea, como compañías de teatro y restaurantes. Todo en C, fastcgi, FreeBSD, postgresql y h2o-server porque siempre hacía lo que queríamos sin doblegarse a las reglas de otros. Era rápido y fácil hacer cambios mientras los cambios no se hacían por nosotros o sin nuestro consentimiento. Nos fue muy bien.
- unixholder
Cuanto más profundizas en tecnologías y frameworks web complejos, más obvio se vuelve que la simplicidad gana.
- benlivengood
Golang también hace posible servir un sitio web o servicio desde un único binario. Incluso puedes evitar enlazar libc si te quedas con Go puro (CGO_ENABLED=0), y viene con todas las librerías http y tls que necesitas para reemplazar el servidor web tradicional (nginx, apache, httpd) también.
Me encanta C y escribí algunos CGIs en C en el pasado, pero no me encanta la programación concurrente en C. Aunque fork y exec pueden usar mmap compartido de solo lectura en segmentos .text, los .bss y .data necesitarán inicialización y copia; hay una sobrecarga de arranque inevitable que un proceso con hilos evita, y pthreads en crudo es algo doloroso. Si todo lo que necesitas es servir un sitio de bajo tráfico, CGI está bien.
Mi mayor preocupación sería con qué frecuencia se respalda la base de datos SQLite porque no hay forma de que un servidor web en C esté libre de RCEs en el mundo actual.
- Levitating
CGI es genial. Lamentablemente nginx no lo soporta de forma nativa a diferencia de lighttpd.
Me gusta este proyecto para agregar CGI a nginx: https://github.com/pjincz/nginx-cgi
También hay métodos para iniciar aplicaciones Rack directamente desde nginx vía passenger[1]. Rack es la interfaz tipo CGI para aplicaciones web en ruby: https://github.com/rack/rack
Permite fácilmente escribir aplicaciones y middleware con unas pocas líneas de ruby.
[1]: https://www.phusionpassenger.com/documentation/Users%20guide...
- creatonez
¿El proceso CGI está abriendo la base de datos SQLite en cada solicitud...? Eso tendría la contención más demencial de la historia.