My recommendation against developing on Apache is twofold:
-
When you’re new to Rails, setting up Apache+FCGI (which is what most
people do when they set out to use Apache with Rails) is often a huge
time-sink. It involves quite a few steps, especially if you don’t
already have FCGI installed and configuired for something else, and it’s
got several tricky bits and gotchas. You can waste a couple of days
easily trying to get FCGI working, especially if you don’t understand
the Rails directory tree and how the Rails dispatch scripts do their
job. -
Assuming you’ve got FCGI or SCGI set up, you’ve got persistence
issues to deal with. You’ll be restarting those FCGI processes
frequently, a whole lot more frequently than someone developing with
WEBrick or plain CGI.
The overwhelming majority of Rails apps only need one server connection
in development mode. Development ususally only involves the individual
developer hitting the app with her/his browser. Things that require
multiple connections for development are edge cases, and by the time you
need it if you ever need it, you’ve probably been working with Rails
long enough and are enough of a HTTP server tweaker that running Rails
under Apache will be much easier than it would be for someone still in
the early learning stages.
My point is not that running Rails under Apache in a development
environment is evil and wrong, but that if you’re not sure why you need
it, you probably don’t need it and your time will be much better spent
on developing your app. If you do need it, you’re probably better
equipped to set it up and deal with the idiosyncracies anyway.
I think too many people come in with a CGI and quick-and-dirty PHP
mindset, in which so much of an app leans on server functionality and
server configuration because of so many years of server-handled
authentication, config.php files full of absolute file paths and so on.
I know that when I code PHP or other CGI-style conventional web stuff, I
want my development environment to closely mirror the production server
and yes, I run Apache on my laptop, because so much that I do references
the server environment. Rails has a lot less of that. If you use
migrations and AR find helpers and you keep your machine-specific path
info to a minimum, you can usually develop on one combination of OS,
database and HTTP server and deploy on entirely another with minimal
fuss.
To each her/his own.
Louis Erickson wrote:
Hi, Steve.
You wrote some strongly worded advice, such as:
On Fri, 5 May 2006, Steve K. wrote:
Develop locally against WEBrick. Don’t develop remotely and don’t
develop against Apache. Apache is for deployment. If you don’t already
know how to configure Apache by hand when it comes time to work on
deployment, consider Lighttpd.
Do not. DO NOT. DO! NOT! DEVELOP! AGAINST! APACHE! unless you’re
developing something that uses Apache for key application functionality,
like an external authentication module. If you’re not absolutely certain
this is your situation, DO NOT DEVELOP AGAINST APACHE. Doing so, except
in the aforementioned edge case, is a waste of time, gains you nothing,
and may in fact hinder you. Later, if circumstances dicate, reevaluate.I’m curious as to why this is such an imperative? This is not to say
that
I disagree with it, but that I don’t see what is so critically difficult
about working with Rails and Apache versus any other platform. Is Rails
FCGI so different than any other FCGI? Or is this merely a warning that
working under a persisted FCGI environment can be a pain?How would you suggest developing applications that require multiple
connections back to the server? WEBrick is single-threaded and won’t
handle simultaneous requests. Is this one of the edge cases that
requires
development under Apache or is there a method to do this I simply
haven’t
seen yet?–
Louis Erickson - [email protected] - Lou's Home Page!The best thing about growing older is that it takes such a long time.