←back to thread

Remember FastCGI? (2021)

(brokenco.de)
53 points heavensteeth | 3 comments | 08 Apr 25 12:00 UTC | HN request time: 0.566s | source
Show context
miggol ◴[11 Apr 25 09:48 UTC] No.43652150[source]▶
Similar protocols like ASGI for Python are still ubiquitous. I assume because they offer separation of concerns and as a result good performance.

You would think the separation argument would still hold true for compiled languages, even if performance is no longer as relevant.

replies(1): >>43652273 #
1. zokier ◴[11 Apr 25 10:10 UTC] No.43652273[source]▶
I don't think interfaces like ASGI/WSGI etc are that similar to FastCGI. The crucial difference is that FastCGI is a protocol, something you need to do IO for and crucially something you need to parse. In contrast ASGI etc by virtue of being in-process and specific to the language can provide an true API. In many ways FastCGI is closer to HTTP than ASGI.
replies(2): >>43652708 #>>43654852 #
2. miggol ◴[11 Apr 25 11:36 UTC] No.43652708[source]▶
That does make sense: an application server like Gunicorn talks ASGI with the application, but Gunicorn itself speaks plain old HTTP with the outside world (or reverse proxy). No more need for FastCGI inbetween.

That is in line with what the article is saying. Thanks for clarifying.

3. whalesalad ◴[11 Apr 25 15:20 UTC] No.43654852[source]▶
WSGI and FastCGI are not mutually exclusive. They talk to each other. They can both be part of the same stack.