3 ms·
If you find yourself with a scripted language where processing HTTP requests might be too slow or unsafe, I can still see some utility for FastCGI. For most of
by ryao 2y ago
If you find yourself with a scripted language where processing HTTP requests might be too slow or unsafe, I can still see some utility for FastCGI. For most of the rest of us, HTTP won, just write little HTTP webservers.
Without serious development effort, I would expect using an existing web server with FastCGI is faster than writing your own web server. It is also more secure as the FastCGI application can be run as a different user in a chroot, or a namespace based sandbox like a docker container.
- usef- 2y agoI was thinking that. Was FastCGI a child of a world where we had neither good library use ("import net/http"), nor (much) layering in front of the server (balancers / cdns / cloudflare etc). So it made sense to assume a production-level layer on the box itself was always needed? I remember the vigorous discussions comparing security of Apache vs IIS etc
- phire 2y agoPartly. But I suspect it's more that CGI was the way things had always been done. They didn't even consider doing a reverse proxy. They asked the question "how do we make CGI faster" and so ended up with FastCGI. Other developers asked the same question and ended up making mod_php (and friends), embedding the scripting language directly into the web server.
- chasd00 2y agoIirc most of the content was static html/css in those days. Running code on a request was rare so cgi was like a bolt on to a static content server. It was available but not the norm. Perl and php gradually made it the norm to run code on every request.
- mdpye 2y agoI remember in the very early days as a hobbyist working with cgi perl scripts for forums or guest books where the script just edited the "static" content in place. The script would write new html files for new posts and do "fun" (I mean, terrifying) string manipulation on the main index to insert links to posts etc. Sometimes they used comments with metadata to help "parse" pages which would see edits. These both were, and definitely were not, "the days" :D
- BobbyTables2 2y agoSure beats maintaining a custom webserver written in C!
- zokier 2y agoUsing HTTP does not preclude having a reverse proxy. So the only difference between FastCGI and HTTP is really what protocol your proxy and your application use, and I don't really see why FastCGI would be major win there.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- ryao 2y agoGiven that the article’s comparison is between a HTTP server with fastCGI, and writing a little HTTP server, the web server with fastCGI will scale better, contrary to what the article suggests. It also would likely be more secure. Reverse proxies are tangential to this.
- assimpleaspossi 2y agoThis is exactly why my web dev company used FastCGI for all our development and would still today if I didn't retire it just two years ago. Wherever we needed faster interaction, FastCGI did the job and allowed us to interface with anything in the backend including our C programs.
- ryao 2y agoWhy did you retire it?
- assimpleaspossi 2y agoMy biggest customer was a national restaurant chain that thought they should have it all in house. So far, a big mistake. My second biggest customer went out of business. Which left us with a bunch of itty-bitty businesses that I'm just too tired to be chasing after.
- myaccountonhn 2y agoI just this week implemented an SCGI server, its even easier than FastCGI and the performance difference is arguably negligible. The parser ended up being 30 lines of code.