"When I searched the first time, most of the answers that I found revolved around using things like “FastCGI with PHP” . I wasn’t gonna use PHP to call a bash script, that would be overdoing it probably."
FYI. You don't have to use PHP to make use of FastCGI. You can simply use something like fcgiwrap (apt-installable on debian) and use it in Nginx.
Yeah, this seems nice for small scripts and all, but I wonder how long until scope creep makes them end up writing or replacing this with an API gateway?
Many things we’ve dispensed with long ago seem to be forgotten and the younger coders are learning for themselves the hard way. Aka the same way we did.
Nginx probably somewhat-deliberately has FastCGI but not regular CGI for a number of reasons.
CGI has process-per-request overhead.
CGI typically runs processes as the user the webserver is running as; said processes can generally read and write to the unsandboxed address space of the calling process (such as x.509 private certs).
Just about any app can be (D)DOS'd. That requires less resources with the process-per-request overhead of CGI.
In order to prevent resource exhaustion due to e.g someone benignly hitting reload a bunch of times and thus creating multiple GET requests, applications should enqueue task messages which a limited number of workers retrieve from a (durable) FIFO or priority queue and update the status of.
Websockets may or may not scale better than long-polling for streaming stdout to a client.
When using Apache, PHP was mostly commonly deployed as an Apache module (mod_php.) Almost nobody ran it as CGI unless they had no other choice. mod_php felt very, very fast compared to alternatives.
I remember doing "custom compiles" for a number of local early web host / Internet providers because their admins didn't want to build C code.
Thank you for the kind words! The general consensus on the article is "why don't you just use CGI", and suppose you guys are right. I just didn't find CGI to be in an option in the searching that I did. I'm surprised too, looking back now tbh.
This is awesome! Thanks for sharing it. I, too, have unintentionally recreated existing technologies (a unix util, pass, in my case).
I recently built something similar with node + bash scripts. Node basically just verifies the webhook, runs a bash script, on failure it rolls back and emails me.
27 comments
[ 1.7 ms ] story [ 70.3 ms ] threadHave you seen zerotier (the software)'s idea too? They ask you to import a GPG key and verify it before chaining it into a |sh or |bash.
FYI. You don't have to use PHP to make use of FastCGI. You can simply use something like fcgiwrap (apt-installable on debian) and use it in Nginx.
https://github.com/donatj/hookah
CGI has process-per-request overhead.
CGI typically runs processes as the user the webserver is running as; said processes can generally read and write to the unsandboxed address space of the calling process (such as x.509 private certs).
Just about any app can be (D)DOS'd. That requires less resources with the process-per-request overhead of CGI.
In order to prevent resource exhaustion due to e.g someone benignly hitting reload a bunch of times and thus creating multiple GET requests, applications should enqueue task messages which a limited number of workers retrieve from a (durable) FIFO or priority queue and update the status of.
Websockets may or may not scale better than long-polling for streaming stdout to a client.
I remember doing "custom compiles" for a number of local early web host / Internet providers because their admins didn't want to build C code.
I recently built something similar with node + bash scripts. Node basically just verifies the webhook, runs a bash script, on failure it rolls back and emails me.