Arrow’s History and Design Philosophy

Arrow started as a web framework written for a now-defunct company called RubyCrafters that a friend and I started in 2003 to try to capitalize on what we anticipated would be a growing interest in Ruby, which had at that time only recently become well-documented in English (thanks Dave and Andy). It turns out that we were right, but that we’re both much better at writing code than marketing our skills, so we had to close the doors before we or the Ruby market really got any momentum. We did, however, have a year’s worth of Ruby and C code that was still eminently useful.

Why another web framework?

We started writing this framework because in 2003 there were only a handful of web frameworks, none of which we felt provided enough high-level functionality for web programming. Tasks like untainting and validating form data, abstracting out HTML from code, and function dispatch based on URI had to be written over and over, each time introducing the potential for new bugs and reducing the time developers had to write the code unique to the application.

A few months before our first public release, Rails came out, and we considered dropping development of Arrow altogether. I tried out Rails, talked with David on IRC about his new framework, and wrote a few commercial applications using it, but there were several things that I kept tripping on, so I resumed Arrow development for my own apps in 2005.

There were several reasons I decided to continue using Arrow despite the overwhelming enthusiasm for locomotive-themed web frameworks.

The first is performance. I’ve heard all the FUD about Apache and mod_ruby, but I’ve seen first-hand evidence that refutes it. I’ve been a programmer for almost 12 years as of this writing, deployed code for several very high-traffic sites (Livejournal, Active.com), and my experience with Apache and an embedded interpreter has shown it to be a stable, fast, and extremely flexible to deploy applications for the web. I’ve seen Apache and mod_perl handle 40-50 million dynamic page views per day, and I trust that experience over uncorroborated conjecture and new-shiny-toy appeal of the web server du jour any day. I’ve been using Arrow in production for both intranet and Internet-facing applications at LAIKA for a year and a half and it’s been rock-solid.

There’s a Rails adapter for mod_ruby of course, but Rails has some fundamental design decisions which make it unsuited to run in a persistent interpreter, especially one in which it isn’t the only application.

Rails (when I was trying to write web applications in it, anyway) also doesn’t run under Ruby’s $SAFE system, and relies purely on validation in the Model layer for ensuring that untrusted user input is in the form the application expects it in. I have strong objections to letting untrusted data get anywhere near my domain objects, but maybe I’ve just read the The World Wide Web Security FAQ too many times. With ActiveRecord’s use of SQL placeholders and validations maybe no one’s ever had a SQL injection attack or a mailer hijacking exploit in a Rails app, but I’d rather have the assurance of running in an environment that reduced the chances of the inevitable oversight or a lazy developer from causing data loss or theft.

There are of course any number of other brilliant, clean, well-designed Ruby web frameworks now, written by people who are probably much smarter than me. If you don’t have a compelling reason to switch away from your favorite, then I won’t try to persuade you otherwise. If you want to give Arrow a try, then hey, thanks for being curious.

Design Goals

Our primary intent when creating Arrow was to make development of applications using mod_ruby as easy as writing CGIs, but with the repetitive and boring stuff factored out for you.

Some of the good things we wanted to preserve from the CGI environment:

• Immediate gratification — we wanted to preserve the “tweak the code and reload” of CGI development to encourage small incremental development and experimentation.
• Simplicity — we didn’t want to have to worry about things like headers, query parameter parsing, response buffering, and the other stuff that CGI libraries typically provide, but we still wanted to be able to access or override those things with minimum effort when necessary.

CGI also has some bad parts that we wanted to eliminate:

• Startup time/fork overhead — CGI has to fork an interpreter each time, load all required libraries, establish new connections, etc. There are accelerators for mod_ruby that eliminate some of this, but usually at the cost of additional complexity or fragility. We wanted to be able to have persistent connections, with little or no startup cost beyond the initial server startup.
• Monolithic code — CGIs of any complexity are usually large chunks of code, with some kind of internal dispatch to manage different actions or parts of the URI space. We wanted to be able to attach smaller pieces of code to paths in the URI space in a way that let control pass through multiple components without them having to know too much about each other.

We also wanted to add some features which are useful in most all web application programming:

• Templating — To separate presentation HTML from application logic, we decided to provide an integrated templating system that uses valid XHTML documents (or document fragments) for templates. We also realized that there are already many excellent templating systems available for Ruby, and so we tried to make it as easy as possible to use your own preferred templating library instead of ours if you should so choose.
• Sessions — Many web application developers find it necessary to maintain state between connections in their applications, so Arrow includes sessions that are very easy to use, but can be configured to use one of a number of different configurable strategies on the back end for storage, locking, and key generation.
• Argument validation/untainting — Web applications need to handle input from end users which needs to be untainted and validated against a definition of what constitutes legal data. Fortunately, Travis Whitton already wrote an excellent Ruby data-validation library called FormValidator, support for which is built into Arrow.
• Modular applications — Very often, web applications need to share several subsystems (e.g., authentication/authorization, state checkpointing and validation, etc.) which are orthogonal to the main application logic but still necessary. Arrow allows some apps to act as delegators, providing some functionality for all apps which are chained through it.
• Graceful error-handling — Sometimes applications fall on their face, and there is little more frustrating than having to track down an error trace from within the bowels of your app. Arrow provides a customizable error-handling mechanism that can be used to speed development and act on errors intelligently.
• Strong introspection — One of Ruby’s strengths is its strong introspection features, and we wanted to build on those strengths. Arrow has some powerful introspection facilities that let the developer examine the state of applications, templates, sessions, etc.