21 Dec 2009

Three Ways You Can Speed Up Your Fresh Rails Development

Author: ceefour | Filed under: Rails

A Ruby on Rails web application I’ve been developing uses Dojo-based full AJAX frontend. I learned some new tricks during development, relearned old pitfalls, and found some mistakes that I’d like to share with you.

execJumpingHurdle 300x300 Three Ways You Can Speed Up Your Fresh Rails Development

Our team decided to implement the webapp in a non-conventional approach, using Dojo Toolkit-based full AJAX frontend, without using any ActionView functionality. It turned that it went quite well, but there are some things that we weren’t aware of and now we know how to deal with it, and you will too. icon smile Three Ways You Can Speed Up Your Fresh Rails Development
Communication between backend and frontend is done using JSON REST API. Since there is pratically no view code in the server-side app, theoretically it would be more appropriate to use Sinatra instead of Rails. But we opted for Rails because of familiarity with all its eccentricasies and exoticism. It’s not so much about learning the Sinatra framework, but more on what if we need to hack things out? (which we have personally proven to be time consuming)

1. Make Good Use of Integration Tests

Since the app uses SOFEA-style (Service Oriented Front End Architecture), I thought backend tests aren’t so critical as it’s replaceable by the front end (which is separate) itself.

I was mostly wrong. Unit tests are still needed to test the backend implementation (with regard to database).

But to my surprise, integration tests are more important than ever, even more than functional tests.

Functional (controller) tests have limited use, I tend to skip it and it can even be misleading. Example: rendering string as JSON only outputs the string, but controller test won’t know that, while integration test detects that the returned JSON is incorrect. Let me illustrate with a more concrete example.

Wrong output:

@message = "Hello World"
render :json => @message

Correct output:

@message = "Hello World"
render :json => @message.to_sym

The first example returns just: Hello World, without quotes, which is an incorrect JSON. Since JSON is parsed, a simple string must be surrounded by quotes (and encoded), hence the to_sym ‘hack’.

2. Scaffolds Are Your Friend (or Leave Your Admin UI Alone for Now)

We thought we’d say good bye to ActionView. Well, we did, but not to scaffolds.

At first we focused on building the Admin UI, not so long before we realize we’re trying to do something Rails is good enough to do it for a few (milli)seconds: scaffolding.

Building the UI with Dojo, Dijit, and DojoX was fun. When you get to know JavaScript more, it’s not as scary as its reputation. And the resulting UI is awesome.

But we spent too much time building the Admin UI with Dojo. It’s not that the UI is hard or that we won’t need it, but we don’t need it now.

Schemas may evolve (migrate), as development progresses, and we couldn’t care less about how the Admin UI looks at this point.

Another plus for Rails scaffolds (whichever your preferred flavor) is it can directly reflect the database. Not true with Dojo-based one. You can rake db:migrate or change the model and voila, your Admin UI instantly has your changes.

3. Start Small

Two previous tips were more concrete, but this one is less of an action and more of… Less.

We tried to do more with more. We actually did less.

Especially during new development, you need as much instant gratification as possible.

Do less with more.

Do something that 80% works with only 20% effort. Or better, something that 60% works just by using 1% of your time.

I wrote specs too, the JSON specs, resource model, REST conventions. It looked pretty good… until I found out it’s not trivial to implement them in the server (and sometimes in the frontend).

Not that it’s not possible, but doing that will mean lots of additional logic in the controllers. Especially since Rails isn’t primarily geared to being a REST resource framework, but a server-side MVC web framework with REST support. Even worse, these logic are duplicated in all controllers, and while trying to refactor them out, it feels like I’m building a new framework of its own.

My workaround was simple: Code what the app is supposed to do.

Leave the snazzies, extras, and toppings for later.

And write tests.

Summing It Up

I’ve to say that I have been enjoying developing a SOFEA-style web application in Rails. Probably there is a better way, yet Rails is quite general-purpose: Rails doesn’t restrict us from doing what we wanted.

Writing backend tests is more important in SOFEA-style than traditional MVC webapps, because the frontend may not be fully developed and you need the tests to make sure the backend works.

Liberal use of Rails Scaffolds saves time. And start with the shortest code that works.

I want to know about your experiences too, please share it in the comments.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Tags: Ajax, API, Cloud standards, controller, Dojo, JavaScript programming language, JSON, Representational State Transfer, resource model REST conventions, Ruby on Rails, Software architecture, web application, Web application frameworks, web framework

  • Pingback: Tweets that mention Three Ways You Can Speed Up Your Fresh Rails Development | AdaRuby --

  • Chris Conrey

    Great summary – would have been interesting to see in Sinatra, but I understand why you went Rails. Best part:
    “My workaround was simple: Code what the app is supposed to do.

    Leave the snazzies, extras, and toppings for later.

    And write tests.”

    More people should do this and let the toppings come later.

  • Hendy Irawan

    Thanks Chris for the rep up.

    I'll definitely work with Sinatra sooner or later. I'm guessing that
    it won't be too hard porting a Rails JSON webservice into Sinatra.

    I'm interested in your own experiences too.

  • Pingback: Tudung Borong Terbaru