On Fri, 5 Mar 2004, Ruby Baby wrote:

> 
> I run a website that's all PHP now, but was due for 
> a total re-write anyway.  (The old code is a mess.)
> 
> It's more MVC style - where the code comes first and
> outputs HTML from templates - NOT embedded code inside HTML.
> 
> I love Ruby so much that it's very tempting to write
> my new version in Ruby (mod_ruby + Apache).
> 
> But I wonder if anyone who has already done a whole
> interactive website in Ruby/modruby could share their
> experience with it?

Yes.

One of my clients, a mutual fund, has their entire site powered by Ruby.  
The basic need there was that the way the site was designed, they have two 
different versions of content occupying the same URL space.  One version 
is public, and the other is private for brokers, distributors, and other 
financial professionals.  So, the Ruby underneath takes care of delivering 
the right content for a given request, depending on whether the requestor 
is logged in to the private version or not.  At the same time, the code 
also takes care of all of the various dynamic content pieces.  I can't 
give a URL to this site because of a confidentiality agreement.

I am redoing my company website, though, and it also has Ruby sitting
behind all of it.  In this case, the framework takes care of handling the
navigation menu, header and footer inclusions, a client login section
where customers can view and pay invoices online, some simple dynamic
content demos, a client facing system status display where customers can
see a live and current display of the operational status of their systems,
and delivery of a correct stylesheet based on the type of browser making a 
request.  I'd rather have two slightly different stylesheets than have one 
stylesheet with gross hacks in it to deal with differences in browser 
implementations of CSS (thought te CSS that I have now still has a slight 
issue with Opera).

Not all of these bits are online, yet, but feel free to take a look at 
what is done:

http://enigo.com

It's all done under Iowa.  The stuff that is just plain HTML is just plain 
HTML files, but where there is something dynamic going on, there is a code 
file associated with the HTML that contains the Ruby that handles the 
dynamic bits.

The site redesign for my Iowa tutorial and documentation(the new versions 
of which are not ready to be public yet), is done in much the same way.

The way that this all works is that there is a mod_ruby handler that is 
setup to take a first crack at requests:

  RubyRequire '/apache/mod_iowa'
  <Location />
    RubySetEnv IOWA_SOCKET "localhost:12345"
    RubySetEnv MAP_FILE "/usr/local/htdocs/enigo.com/mapfile.cnf"
    SetHandler ruby-object
    RubyHandler Apache::Iowa
    RubyTransHandler Apache::Iowa
  </Location>

High level nutshell -- when Apache geta a request that matched the 
location specified, it passes it to the handler.  If the request is for a 
URL specified in the mapfile.cnf file, then the handler issues a request 
to the socket specified in the IOWA_SOCKET variable.  This request is 
basically a Marshalled clone of Apache::Request, giving the Iowa app full 
access to the HTTP headers, query_string parameters, etc...  This 
Iowa::Request can be thought of as a Marshalable 80% close of 
Apache::Request.  It also works outside of mod_ruby, populating the 
Iowa::Request with data pulled from the standard CGI environment 
variables.  Anyway, the request is passed off to Iowa.  Iowa, running in 
this way, will lookup the URL requested in a mapfile on its end, so that 
it knows which class to use to handle the request.

Unless specifically specified in the associated code file, the class for a 
plain HTML file is derived from the filename.

So, for examples:

Index.html becomes Iowa::Application::ContentClasses::Index
Gerbils/FAQ.html becomes Iowa::Application::ContentClasses::Gerbils::FAQ

and so on.  This leads into one of the few current required naming 
conventions.  A filename has to follow Ruby rules for a valid class name 
(the part before the .html, that is).

It all works very well.  I can put a site with dynamic content together 
quickly because I can leverage Ruby, and I can still use plain old HTML 
for all of the areas where I want that.  I have zero problems with it.  
The Iowa process doesn't have a very large resident set size, even for 
sites that have a lot of content and require a larger session cache than 
the default 10.  It's relatively fast.  Speed is dependent on the size of 
the content being returned and on just how much processing is required to 
generate the dynamic stuff.  On Ruby 1.8.1, on an 800Mhz test box, I 
get around 35-40ish pages per second for relatively simple pages like the 
Enigo navigation & homepage.  On 1.6.8 it is somewhat slower, and seems to 
evoke a threading bug if hammered for lots of hits per second, causing a 
segfault.

So, I suppose my whole point here is that Ruby/mod_ruby can definitely be 
used to power an entire web site.  No problem.  The issues all really come 
up depending on whether you are using some framework like the recently 
posted about 0.2 release of SWS or Iowa or something else or whether you 
are using eruby or....  Each of these is going to have different strenghts 
and weaknesses.


Kirk Haines