←back to thread

Remember FastCGI? (2021)

(brokenco.de)
53 points heavensteeth | 4 comments | 08 Apr 25 12:00 UTC | HN request time: 0s | source
Show context
ryao ◴[11 Apr 25 09:33 UTC] No.43652062[source]▶

  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.
replies(4): >>43652278 #>>43652341 #>>43654110 #>>43671603 #
1. zokier ◴[11 Apr 25 10:25 UTC] No.43652341[source]▶
Using 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.
replies(3): >>43655728 #>>43655779 #>>43655823 #
2. ◴[11 Apr 25 16:35 UTC] No.43655728[source]▶
3. ◴[11 Apr 25 16:39 UTC] No.43655779[source]▶
4. ryao ◴[11 Apr 25 16:43 UTC] No.43655823[source]▶
Given 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.