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.

2 comments on “Musings on the future of FastCGI

  1. dlh January 6, 2006 5:05 pm

    I forgot to tie in James Duncan Davidson’s related musings on the subject here:

    http://duncandavidson.com/essay/2006/01/railsonapache

    Which are also really good. In his case he’s talking specifically about how to get rails going but he ends up in a similar place, ie, proxy it out.

  2. Mark Mayo January 6, 2006 7:02 pm

    Thanks for dropping by! Duncan Davidson’s post was also a good read, thx for the link.

    And you can call me Mark, not “vmunix”, if you want. :)

Leave a Reply

Your email address will not be published.


8 × eight =

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>