What is the difference between FastCGI and an in-place HTTP server (such as Swazoo or Hyper)? Probably the most important difference is that Hyper provides a full HTTP Server so you don’t need another HTTP Server (such as Apache). In essence, both HTTP and FastCGI are doing the same thing–receiving a request as a ByteArray on a socket and sending a response as a ByteArray on a socket.
The reason FastCGI exists is because when we started porting Seaside to GemStone, I did some research and came to the conclusion that FastCGI was a good way to interface between an HTTP Server and an Application Server. Since then, I’ve learned about other approaches, including “reverse proxy” in which the HTTP Server forwards the request using the HTTP protocol rather than the FastCGI protocol. People whose opinions I respect have said that FastCGI provides no significant advantage over reverse proxy with a second (built-in) HTTP Server. On the other hand, FastCGI seems to be in use in various systems other than GLASS, so I assume it has some advantages.
Göran Krampe recently showed “Blackfoot,” a SCGI server in Squeak. Some others have compared FastCGI to other approaches. Take a look at posts by Mark Mayo (with an update here), Ian Bicking, and Pedro Melo.
In any case, the nice thing is that GemStone is a Smalltalk platform in which various approaches can be used. The value of GemStone is trivial persistence and scalability; the choice of implementation approaches is up to you!