Frameworking

December 11th, 2007 by Ben

We’ve just started on the first phase of a new project, step one of which (for me) includes deciding which technology platform we’re going to be using. We want something that lets us get working prototypes built quickly, changes to the system design implemented with as little pain as possible and, crucially, allows the system to perform and scale well after deployment (with the minimum of hand-holding).

Coming from the ((un)enviable) position of being mostly language-agnostic, I’m looking at a few different web application frameworks to assess their suitability.

There are a couple of obvious problems

  • Very few objective comparisons exist of the different frameworks out there, using realistic sample applications.
  • Short of implementing the entire application during the evaluation process, it’s nearly impossible to get an idea of the framework’s performance.

The contenders
We’ve yet to write any code in anger, so the comments below are based on books, examples, tutorials and entirely too long searching Google.

We’ve looked at:

Rails (Ruby)
http://www.rubyonrails.org/
From what I’ve seen so far, I like the Rails development process. I know a lot of people don’t, but I’m willing to step forward and be categorised as one of ‘those‘. I have some serious concerns however, mostly in relation to performance and deployment:

  • The recommended method for deploying/hosting a Rails app sucks. Considering how much thought has gone in to the rest of the framework, the idea of having to set up and monitor individual Mongrel instances behind a proxy to run my app feels like it was borne out of repeated attempts from the Rails community to stop their applications dying under load; bear in mind that this isn’t something you do to tune your site, but something you do just to get it managing requests acceptably.
  • I’m not entirely comfortable with ActiveRecord’s ability to generate well-performing sql (although I suppose this concern is one of ORMs in general). There are reports of people having to replace it with hand-written queries when going in to production, particularly in the case of associations. Is this true of all ORMs? Maybe …
  • Twitter. Boy do they have a lot of downtime. This fuels worries about performance and the kind of day-to-day maintenance that a live Rails app needs.
  • It’s trendy, and I don’t mean that in a good way.

We are going to be looking at:

Django (Python)
http://www.djangoproject.com/
The performance figures are encouraging for Django, and the fact that a memcached-backed caching layer comes as part of the framework indicates the thought that’s gone into it post-deploy. So far, a couple of things are bothering me:

  • It seems geared up for use in publishing (understandable, given its background). However, the sort of sites we’ll be building will be very interactive, with a lot of two-way data exchange - I worry that Django isn’t going to help us much in this area.
  • The whole Python whitespace thing is … well, I’m in the ‘hate’ camp on that one (although the language itself looks intriguing)

Catalyst (Perl)
http://catalyst.perl.org/
I need to do a lot more investigation here, but two people now whose opinions I respect hugely have told me I should be using Catalyst. It’s the least well ‘marketed’ of the three but word of mouth recommendations are worth a lot.

Information is a little light on the ground regarding real-world performance, but it’s Perl so it will be fast. The Perl community has been around for a little while, so there’s plenty of prior art in getting Perl web apps to scale.
For me, the one obvious problem is the very thing I like so much about Perl:

  • TIMTOWTDI. One of Catalyst’s big selling points is the fact that, if you don’t like the default ORM, templating language etc, you can swap it out for a different one; essentially you get the whole of CPAN to play with. If I were an accomplished OO Perl programmer, this would be a big plus; as it is, I’m something of a Perl *scripter*, so this makes me wonder about the learning curve for Catalyst, and the maintainability of the code between different programmers.

So, the search continues. I need a coffee.

5 Responses to “Frameworking”

  1. Steff Says:

    Now I come to think of it, I recall Toby mentioning Ravenous as being interesting: http://ravenous.solidosystems.com/ - it should be scalable as all hell if nothing else.

  2. Andres Quijano Says:

    How about JRuby on Rails? or Grails (http://grails.codehaus.org)

  3. Ben Says:

    Andres: If you’ve used Grails and think it’s worth considering, I’d love to hear your comments.

  4. Andres Quijano Says:

    Nope, I haven’t used Grails in a real production envorionment. A new framework (along with the language) that look very promising (although today it’s in early development) is Lift, built on Scala: http://www.liftweb.net

  5. Mike Whitaker Says:

    TMTOWIDI with Catalyst, true.

    BUT, and it’s a big but, there IS an accepted way (Template Toolkit for your views, DBIx::Class for your models), and quite frankly development using that absolutely screams along. For the last Yahoo! Hack Day I built a Catalyst app from scratch to emulate another RESTful interface within the company in about 10 hours, most of which was wire-sniffing the REST protocol :)

    You’ll find that’s what most folks use, that’s what the book ( http://catwiki.toeat.com/thebook ) advocates, and it just plain works. There’s maybe half a dozen concepts you need to get your head round to do basic CRUD, and then wham.

    Where TMTOWTDI scores is that when some bright spark of a CTO says ‘we must do user auth by talking to a Radius server’, or ‘all our web content is stored on a WebDAV server’, you can leverage the wonders of CPAN to replace your model class with one that DTRT.

Leave a Reply