Re: FastCGI still a smart choice in 2010?

On 4/20/2010 7:32 PM, Sven Svenson wrote:
> What's happened with the attitudes developers have about FastCGI? It
> seems that FastCGI is not the preferred way of deploying web
> applications outside the Perl world. Are the Java, PHP, Ruby and
> Python folks right to be using something other than FastCGI?

Java is an interesting case, because trying to stay true to the "compile once,
debug^H^H^H^H^Hrun anywhere" idea leads naturally to "the whole stack is in
Java."  Once you get there, language-generic standards like FastCGI aren't
nearly as interesting.  You also need a massively complex set of standards and
APIs in order to make the whole thing sufficiently "enterprise ready." :-)

As for PHP... um, my web server runs quite a bit of PHP via FastCGI.  Works
great, and lets me isolate PHP applications (file access, privilege, etc.)
enough that I feel *comfortable* running PHP applications.

Ruby (...on Rails, particularly) is a sad case, there are quite a few
completely different and incompatible approaches to handling the web
server/RoR communication layer, each one trying to make RoR performance less
apparent.  I'm not sure there's *that* much consensus on the 'right way' to
deploy Ruby on Rails applications, but FastCGI is certainly one of them.

Python... I thought the standard way of doing things in Python was WSGI, which
can be (and has been) implemented on top of FastCGI.  Depending on which web
server you choose for the other side of WSGI, FastCGI underneath may or may
not be the best choice.

Past that, I've seen some interesting work in using FastCGI to provide a
low-impact embedded web application in a program that is, overall, not a web
application - without having to have an entire HTTP stack embedded.

And regarding "high performance" web sites, some of the fastest web servers
around - such as lighttpd and nginx - rely on FastCGI to support secure,
platform-agnostic, fast web applications.  Apache's FastCGI support may not be
as good, but they tend to prefer emebedding everything in monstrous insecure
processes anyway. :-)

(Lots of bombast here, everyone should free to provide more balanced views
should they desire!)
-- 
 Matthew Weigel
 hacker
 unique & idempot . ent