Traffic for our Passenger (mod_rails) preview site has increased three fold ever since RailsEnvy and weblog.rubyonrails.org (thanks David) linked to us. We’ve received quite some emails from interested people. 🙂 One of the questions that we receive most is:
“What about other Ruby frameworks, like Merb, Camping, etc?”
There is the following saying: jack of all trades, master of none. At the moment, our goal is to make Passenger a great deployment system for Ruby on Rails, one that is matched by none in terms of ease of use and low maintenance overhead.
But some people ask:
“What’s wrong with mod_ruby?”
- For one, look at its website. Last release was from 2006. I’m not sure whether it’s still maintained anymore.
- Nobody (or almost nobody) uses it in production. This fact alone says a lot.
- The Rails wiki page for mod_ruby lists a pretty bad limitation:
mod_ruby uses a shared interpreter per Apache process, which means that multiple Rails applications on the same Apache setup with mod_ruby would share the framework classes. This doesn’t work well with the Rails model of using class-level configuration attributes, so it’s considered unsafe to use mod_ruby and Rails with more than one application running per Apache setup, because different applications may start sharing the classes.
Granted, these are implementation problems and not conceptual problems, so they can be fixed. So some people ask:
“Why didn’t you just make a solid mod_ruby implementation?”
First, we must agree on the premise that Rails is a more popular framework than other Ruby frameworks. Wait, hold your flame thrower, this is not the reason. 😉
Next, try thinking from the point of view of a new Rails developer. He’s introduced to lala-land: Don’t-Repeat-Yourself, convention over configuration, stuff that’s supposed to Just Work(tm).
Then he deploys his Rails app and finds out that he has to setup a Mongrel cluster (1 command but usually with 3 or 4 options that he’ll have to look up), configure Apache to proxy to the cluster (about 5 or 6 lines that he’ll have to setup), configure init.d/daemon tools/monit/god/whatever so that his Mongrel cluster is started at system startup, etc.
Oh, and you need to repeat this for every single Rails app.
Ouch, is this the proper Rails experience? I don’t think so. This is Passenger’s philosophy: deployment should be in line with the Rails philosophy. In other words, it should be brain-dead simple. Just imagine the money that you’ll save on health care for your system administrator if he doesn’t have to worry about all that stuff anymore. 😉
Of course, the Rails philosophy doesn’t prevent deployment of other Ruby framework apps from being easy. So what’s holding us back? Well, here’s a few things that Passenger does but mod_ruby doesn’t:
- Remember the screencast that we showed you? You can deploy a Rails app to a virtual host without any Ruby-specific or Rails-specific configuration! From this fact one can deduce that Passenger somehow automatically detects Rails applications (and yes, this autodetection can be disabled). Autodetection heuristics are framework-dependent. We’ll need different heuristics for each framework.
- Passenger preloads framework code and application code in order to reduce startup time and to reduce memory usage. Preloading logic is framework-dependent.
- Look at Troubleshooting obscure errors with mod_ruby. Notice the word “obscure errors” – errors should never be obscure or hard to track!
We’ve seen many people failing to deploy Rails apps because of errors during application startup. Lighttpd’s FastCGI implementation redirects those errors to /dev/null. Not good, this fact bit me 2 years ago — when I was deploying my first Rails app — and made me wonder why the thing wouldn’t work. Mongrel prints errors either to stderr or to its log file. But people who are new to Rails deployment don’t know that they should be looking in the log files (or that there are log files in the first place). Plus, looking into the log file is yet-another-step. Wouldn’t it be great if you can see startup errors right in the browser?
Passenger provides user-friendly error pages. If a Rails app failed to start, then Passenger will tell you what happened. A few possible error pages are:
- Whether a (specific version of a) system-wide Rails framework failed to load. Passenger will even tell you the correct command to (re)install it.
- Whether a vendor’ed Rails framework failed to load.
- Whether the app failed to start because of a syntax error, or a missing gem. Passenger will suggest solutions.
- Whether a database error occured during startup. Passenger will tell you to check your database.yml and to run ‘rake db:migrate’.
As you can see, a lot of these error pages are framework-dependent.
As you may have noticed by now, we’ve put a lot of work into making sure that deployment is dead-easy. This is only possible if Passenger has knowledge about the frameworks themselves. We have a tight schedule and we only have 2 developers working on Passenger. Rails is more popular so it has more priority. We’re working around the clock to get this thing released.
Or we can get rid of the autodetection/preloading logic and just provide generic configuration options. But would you really want that? By no means should we force the system administrator to configure things. By default, stuff should Just Work(tm) out-of-the-box.
Hope this clears things up.