←back to thread

Show HN: A dynamic C (Hot reloading) module-based Web Framework

(github.com)
127 points warothia | 1 comments | 17 Nov 24 18:12 UTC | HN request time: 0.2s | source
Show context
dakom ◴[18 Nov 24 06:58 UTC] No.42170374[source]▶
Love this :)

Small, related anecdote: back in the year 2001 or so, this is in the same family of how I built websites...

The difference is I wrote in in C as Apache Modules. So, like, most people were using other people's C modules (like PHP or CGI), but once you dug deeper and you wrote your logic/site _as_ a C module, it was so much more fun (and powerful too).

I didn't have much of a templating language, so the answer to "can we change the text on this page?" was usually, "sure, just give me a few minutes to recompile the whole Apache server" :D

Fun times

replies(2): >>42170455 #>>42174281 #
warothia ◴[18 Nov 24 07:19 UTC] No.42170455[source]▶
Few others have brought up Apache Modules, and they are incredibly similar to my idea. :D Did not know about them while I was developing it. The main difference as far as I could see was the fact that you had to recompile / restart the server. Which I try to avoid, so little changes require almost no recompiling.
replies(3): >>42170474 #>>42171280 #>>42173764 #
1. mst ◴[18 Nov 24 10:46 UTC] No.42171280[source]▶
In apache 1.3 it was far from unusual to do a complete bundled compile and restart the entire thing every time because there were gremlins that showed up when you dynamically loaded the more complex modules often enough that it was operationally less aggravating overall to take the brute force approach (I did quite a bit of that a couple decades back, for my sins).

apache 2+ is a very different (and rather more robust) beast, and also has the 'graceful restart' system - see https://httpd.apache.org/docs/2.4/stopping.html - which makes the parent tell its worker processes to drain their request queues, -then- exit, after which each one is replaced in turn until you've fully upgraded to the new configuration+code.

This approach has its disadvantages, of course, but not that morally different from how erlang processes hot reload into new code, and once you knew what you were doing the end result was simple, predictable, and nicely transparent to end users.