Riding the Rails with Heroku
Continuing on from last weekends Ruby on Rails fun I’ve continued working the core functionality of Pixel Publish. Ruby on Rails definitely lives up to the hype of being fun to use So far I’ve managed to do almost everything I’ve needed using preexisting gems, leaving most of my work focused on getting a solid domain model designed and working and gluing all the pieces together. This is just a brief review of some of my experiences so far.
The Good
One really cool almost OOTB feature of Rails/Heroku is the delayed job. It is basically a very, very, simple job queue, (word of warning though DJ is technically using SQL as a Queue which is bad). Basically it makes it easy to queue up longer running tasks that should not be performed by the web service (which is a huge relief as I was really not happy with calling ActiveMailer in process). Now a job queue really isn’t anything new, not having to build one yourself or do any real work to get it running in production is seriously frakin’ amazing. It’s even straightforward to auto-scale the worker dyno meaning that you aren’t paying if there is no work to do.
This is really the anti-thesis of my experience with Azure. Aside from not having any real built in modular functionality that can just simple be had (sure Azure Queues, but they don’t actually do anything unless you make it yourself) just try auto-scaling with Azure. Even if it were possible, prepare to wait 10-20 minutes for that worker to start up.
For those thing yeah well DJ is a pretty naive job queue implementation, that’s probably true. However there are also far more robust alternatives like Resque which is built on Redis and like DJ is easy to use with Heroku’s new Cedar stack. However, since I’m still experimenting and since I’m already using Postgres and CouchDB I didn’t feel like adding any more complexity I didn’t need… yet. The point here is simply that there are a lot of options here to just getting s#%t done which is great.
The Bad
As I stated last time getting started with Rails isn’t without it’s hiccups and rails routing seems to be my arch nemesis. This recent example really sticks out as something I find a bit kludgy and ugly. The worst part is how hard it is to diagnose routing problems. There is almost no useful information in the route error other than “No route matched”. Try searching for that on Stack Overflow (3000+ results). Rails routing is a brutal beast in desperate need of some taming.
Though I’m no stranger to this experience, early on when I was learning .NET MVC I found the built in .NET routing options just a bit stale and limited, but quickly found going outside the box was not without it’s own pitfalls. However, I persevered and eventually became a master of .NET MVC routing.
The truth is, I’ve never particularly loved the faux REST style of MVC frameworks, Rails included. The fact is they corner you into a box under the premise of “RESTfulness” and yet it couldn’t be any further from actually being REST. Besides if I’m using MVC I’m probably not building an API, I’m building the site. I think it is still quite hard to do both at once and not compromise one or the other (or both).
It’s for this exact reason we currently use both Nancy and .NET MVC on the project I’m working on. Honestly, nothing beats [Sinatra][sinatra] inspired syntax for designing RESTful APIs. So, why am I not using Sinatra? Well because I’m curious. Rumor has it that despite the routing snags, Rails is still the getting s#!t done king of the hill and I want to make sure I’ve given it a full and proper test drive. So far the good parts far outweigh the bad so trudge along I will.
Next Time: My mixed emotions about unobtrusive javascript