Two months after the end of WWII in Europe, Vannevar Bush published an essay called As We May Think. He introduced a concept called memex, which became the forerunner and inspiration for hypertext.
Forty-six years later, Tim Berners-Lee released the very first web server, called CERN httpd, and a browser that worked on NeXT. Later that same year, Nicola Pellow developed a text mode browser for other platforms. At the same time, on the other side of the planet, Pablo Escobar surrendered himself to the police. CERN httpd’s latest version 3.0 is available on GitHub.
Two years later, NCSA published a specification for calling command line executables. The output of these executables could be rendered back via the web server over an HTTP protocol as a response. This was basically the birth of the dynamic web and ultimately resulted in a formal CGI standard.
Three years of extensive use of this solution showed that launching a separate process for each request and tearing it down at the end of the request was a waste of resources. Let’s ignore the forgotten Netscape server API for a minute and note that Fast CGI was the greatest achievement since CERN httpd. Requests from the web server could be routed to a FastCGI server (via a socket, TCP or named pipe). The FastCGI server keeps data-rendering processes running for a series of requests, so that responses are returned to the web server and then to the client. This approach significantly reduced server load and response time.
Another popular approach that was actively developed during that time is called embedded interpreters. Some well-known examples are Apache’s mod_perl (released in 1996) and mod_php. They basically keep the interpreter running constantly in order to save launch/tear down overhead and to transfer the script code to the interpreter process, which in return renders back the response body. Interpreters usually have access to the web server’s internal APIs and act as extensions of the web server.
CGI, FastCGI and embedded interpreters are still widely used today (Apr 2018).
But all this has nothing to do with frontends. I just mentioned it to give you an overview of how backends render their outputs to a browser. Of course I skipped some basic things like sessions, caching, reverse proxies, database connections because they are less relevant to the big picture.
The big picture is quite simple. A request is received by a web server, which somehow gets the output of the backend application code and renders it back to a client application. In most cases that client application is a browser. As for static HTML / CSS / Javascript assets, the backend application code just reads content from a file (database, Redis, Memcache, tape, punch card or whatever storage is used) and sends the content back.
