A Modern Web App in C

My favorite trivia is that busybox has built-in cgi-bin support (and `rclone serve webdav` seems remiss to not mention as well). `https://elixir.bootlin.com/busybox/1.37.0/source/networking/...`Everything the post mentions is 100% true and well-reasoned, especially with the inclusion of pledge/chroot/etc. for dropping privileges.There's two diametrically opposed deployment mechanisms:1) stack towers of glop on top of each other until you're running a simple `echo "hello world"` on top of a docker container inside a vm in a proxmox server as part of a k8s cluster under a hypervisor running on remote compute...2) just run `bash -c 'echo "hello world"'` and front it with CGI (stateless, single binary, yada yada yada...)Take a peek at https://github.com/Domain/bash.cgi ... not that i'm suggesting that 'bash over busybox using cgi-bin' is the "proper architecture", it's more trying to illustrate that the amount of code that holds you back from being nearly truly "frameworkless" is tiny and easy to reason about.For some of the internal tooling I'm doing for work, I've been tending towards: some-cmd [--json|--markdown] ...yet-more-args...... reply:...

For people who find interest in weird web applications, I have been working on a game project, in C++, where the client is compiled to WebAssembly with Emscripten, and the application server is also implemented in C++ (behind nginx).This is from pre-AI era also. The game is Civ-like. Custom engine from scratch (including both the 3D stuff, and all the web handling also).Take a look: https://statebuilder.com/ reply: I'm also working on an educational game project in C++ compiled to WebAssembly with Emscripten. Absolutely awesome to work with.

I started a web dev company 22 years ago after developing an online menu ordering system for a restaurant I owned. I, then we, did pretty much the same thing as talked about in the posting but we used fastcgi. I started with C because I knew C. That was my real job. It ran so well, the franchise bought the software from me--and then devolved it to all the Microsoft stuff and had issues upon issues from then on out. That's another story.I continued to make sites for other venues that needed online ordering; such as theatre companies and restaurants. All in C, fastcgi, FreeBSD, postgresql and h2o-server cause it always did what we wanted without bending to someone else's rules. It was fast and easy to make changes while changes weren't made for us or without our consent. We did very well for ourselves. reply: Feels so long ago the way you write about it, but 22 years ago was basically 2005

I remember CGI days and I have written tiny web "features" with Perl and C many years ago. All my product backends are now in Rust and SQLite but I use frameworks and libraries. Like Tokio, Auxum/Actix Web, Diesel.I am not sure I like the idea that the binary will be called by nginx on each request. I prefer the backend binary to have state. A 256 MiB virtual instance is enough for any software shared between friends, family or even a small community.SQLite backups are easy. I really like how I am building web apps these days. Been with PHP for 7 years and then Python for 10+ years. Single binaries are awesome. I am looking at multi-server backends as well, still 256 - 512 MiB per instance but with a shared Redis. Still with SQLite. Should easy enable medium sized business software.

Golang also makes it possible to serve a web site or service from a single binary. You can even avoid linking libc if you stick to core Go (CGO_ENABLED=0), and it comes with all the http and tls libraries you need to replace the traditional web server (nginx, apache, httpd) as well.I love C and wrote some CGIs in C in the past but I don't love concurrent programming in C. While forking and execing can use shared read-only mmap on .text segments, the .bss and .data will need initialization and copying; there's unavoidable startup overhead that a threaded process avoids, and raw pthreads is kind of painful. If all you need to do is serve a low traffic site, CGI is fine.My biggest worry would be how often the SQLite DB gets backed up because there's no way a C web server will be free of RCEs in today's world. reply: Shameless plug: if you value Go, and CGO_ENABLED=0, and SQLite, and are worried about C in a web server and RCEs, may I interest you in my SQLite driver?https://github.com/ncruces/go-sqlite3I just wrote up the security goals of the tool I use to translate C to Go:...

I disagree with the first sentence. In 199x the first people I knew making web pages dropped perl scripts, not C programs, into cgi-bin. reply: May have pre-dated you by a bit. Perl definitely took foot not long after but the earliest cgi-bin days were dominated by C before people got tired of fighting compilation for web apps.IIRC the spec itself says it was built for C applications.mod-perl was a godsend, of course.

CGI is great. Sadly nginx doesn't support it natively as opposed to lighttpd.I like this project for adding CGI to nginx: https://github.com/pjincz/nginx-cgiThere's also methods of starting Rack applications directly form nginx via passenger[1]. Rack is the CGI like interface for ruby webapps: https://github.com/rack/rack It easily allows for writing applications and middleware with a few lines of ruby.[1]: https://www.phusionpassenger.com/documentation/Users%20guide... reply: You can write a ngninx module. That would be the actual 2026 way to write C web apps. Used to be a huge pain, but now AI can just read the nginx source and do it correctly.

A Go binary with CGO=0 and all templates/documents embedded gives you a better overall tooling and deployment experience. Put it in a scratch container for complete isolation. reply: CGO=0 came in clutch at previous job when we were deploying Go apps compiled on builders that had a newer glibc than the actual prod server.

The deeper you go into complex web technologies & frameworks, the more obvious it becomes that simplicity wins.

> There's no separate database server. You open the database file through SQLite's C API.> Every request spawns a fresh process.How does it work when multiple concurrent requests are possible? Does SQLite allow simultaneous write access from multiple processes?

came back to C/C++ for same reasons, no supply chain trouble, fits in my head, runs forever, ... here a playground for win32, using partially webview2, all batteries included, openai client , tts, stt, vpl, images, audio, video, ... comes with webview2 apps, settings (and encryption), config, rest server, ipc, testing, CLI11, postgres, installer, doc gen, modbus, OpenCV, daemon, computer use, agent memory, image tools, mcp server/client, experimental flow editor - what a fun and exciting times :) https://github.com/polymech-info/win32-boilerplate

The time is right for AI to generate a basic C web framework just like Node Express with request, response, template, cookies, auth, db, websockets and some other libsIt would be blazing fast, for use by AI itselfJust for fun

Author described good ole PHP 3.Early PHP (3 and 4) were the thin layer over the C libraries and were pretty fast and easy. it came about right when CGI was deprecated and it solved CGI's problems

I just really wish it had some examples of code in there to get a better idea of what is really going on. It sounds interesting.

This could be a defensible choice, reasonable even, if you use Fil-C to guarantee memory safety. Otherwise, I would call it irresponsible.

Is the CGI process opening up the SQLite database for every request...? That would have the most insane contention ever.

impressive!which also makes me wonder if it wouldn't have been more programmer-friendlier had it been written in Perl?

"A modern web application typically puts a web server like nginx in front and reverse-proxies to an application server written in another language like Ruby, Python, Go, or Rust. That always felt a bit strange to me: you essentially have two web servers, and one of them is also responsible for your business logic." -- Is the fundamental difference here that the business-logic binary is not always running but gets spun out with each request? This looks like a relatively minor thing, to be honest.

I was not thinking about vanilla C and CGI but I wrote my own modern web api server app in C++ (std+boost only) and I found it extremely pleasant experience. very reliable and little supply chain/dependency hell problematic too.It’s for intranet business app so although it’s not yet production ready yet, definitively winning against many other modern approaches in web development in my consideration, and quite refreshing POC project.

I love this kind of simplicity. It's unexpectedly satisfying.

It's not very clear to me why the author has chosen C in the first place. I appreciate the effort of sharing the experience with us, anyway.

It hasn't been touched in a long time, maybe that's because it's "complete", but here's a quick CGI library:https://github.com/codazoda/cgi-lib

I have used ccgi.c when I needed access to system calls and PHP was too much of an attack surface.https://github.com/moths/libccgi/blob/master/ccgi.c

I'm still in the middle of reading but I wanted to comment first that I had a pleasantly surprising experience a few years ago with CGI. I hadn't thought about CGI since I was a kid and I was tasked with adding a simple dynamic page to a server that had nothing running yet except apache. For whatever reason I though to try out CGI because of how simple the page was going to be, and yeah. Would recommendI just got C FFI working in my LLVM based language last night so I'll need to take a look at playing around with BCHS :)

i also do that way, but i also have written my own webserver so i have no cgi interface. it serves files and provides "special" sites for the application written in. I use html and css as a frontend. nealy no js code in the html. Things i hate: - applicatin status handling - mixing html, css, js and c in one file - having no web "widgets" - having to make them by myself

Best I can do is use a framework built on top of a framework.

I worked on a FORTRAN 77 CGI application in the early 00s. I think the host was Apache httpd, on some old HPUX version.

And the cycle is born again. Seeing the cost of a rust conversion today, there is an argument...