Musings on the future of FastCGI

This is mostly an uber geeky post for my own uses, though one or two of the folks who stop by here might find it interesting. The musings aren’t mine, they’re vmunix’s, and they’re excellent. I’ve been spending a lot of time thinking about current best of breed we app development environments, for reasons I hope to be able to talk about in a week or two. Today I happened across vmunix’s post, which is a discussion of where the future of FastCGI, SCGI and apache may lie. This is a huge issue in that mostly what I’ve been concluding is that the new MVC frameworks that have emerged over the last year are really the way to go, but deployment of apps based on these frameworks is hampered by their poor integration with apache/2. The question then is what to do, and the answers are less than satisfying. The rails camp, for example, will basically tell you to switch to lighthttpd. I’ve got nothing against lighthttpd in principle (and really it gets great reviews all around) but I have over a decade invested in apache and an attendant nest of code tied to it, so switching isn’t a trivial undertaking and the payoff has to be worth the investment it would take to migrate everything. I’m not convinced it is. Vmlinux’s take is that ultimately either fastcgi or scgi will become a core apache module in the same way that mod_php did, but he also makes the observation that it might make more sense to simply use mod_proxy and proxy requests from apache to a distinct webapp server, taking his cues from how the Java and Zope camps ended up where they are. This is excellent stuff and well worth a read for anyone managing web services or curious about where things are potentially headed.

As to my own conclusions on the subject, I have nothing firm yet. The contention is it’s easier to manage distinct app servers (an instance of lighthttpd with fastcgi for rails apps, with mod_proxy pushing requests over from apache, for example) than it is to build the one apache binary to fit them all. I’ve felt that pain of complex apache recompiles and seemingly irreconcilable dependencies so I know from whence this comes, but I also get leery of this conglomeration of configuration files you’ll then be left managing, such that when an app breaks down you wander around in the disk trying to figure out where the fault is. The bottom line is I need to get some hands on time with a configuration just like this, actually put my hands on it, before I draw any firm conclusions, as well as bounce it off a couple of folks whose opinions I value.

0 thoughts on “Musings on the future of FastCGI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s