←back to thread

53 points heavensteeth | 3 comments | | HN request time: 0.204s | source
1. zokier ◴[] No.43652325[source]
It's baffling how FastCGI ever was popular, considering how weird it's premise is: let's take this well-known standard simple text based protocol and convert it to our own custom binary protocol, that will make writing services somehow simpler?! You are still dealing with all the complexity of writing a daemon, only difference is that instead of parsing HTTP you parse FastCGI.

Maybe today with all the complexity that is with http2/http3 etc it would make slightly more sense. But FastCGI was popular when all the world was just good old plain http1.

replies(2): >>43652435 #>>43653370 #
2. jagged-chisel ◴[] No.43652435[source]
I (the user of the FastCGI library) don’t parse anything. I use the library. Whether it does HTTP or some custom protocol is irrelevant to my coding task. Might be relevant for performance, but who’s building anything big enough to worry about that? ;-)
3. BobbyTables2 ◴[] No.43653370[source]
I think it still makes sense if one wants all the fancy bells & whistles of Apache without reimplementing them in their own webserver.

In some sense, implementing a full webserver just because the world standardized on a horribly inefficient way of handling CGI is pretty silly.

We don’t rewrite “cp” and such just because we want to copy multiple files quickly…

Of course, if the sole purpose is just to handle CGI types of things, then the custom embedded webserver likely makes more sense. Apache is a horribly complex beast.