

How we used Rails & Backbone.js to build a lightning-fast webapp. - adrianpike
http://adrianpike.tumblr.com/post/25812863078/how-we-used-rails-backbone-js-to-build-a

======
taterbase
Awesome to see you guys utilizing a few different technologies to their
strengths and not going the "silver bullet" route.

Regarding your "Update resource B when A changes" situation you can use
Backbone's callback hash

    
    
      var self = this;
      this.save(null, {
        success: function(model, response){
          self.trigger('updateResourceB', response);
        }, 
        error: function(model, response){
          //Error handling
        }); 

saving Resource A to fire an event that Resource B can listen to and perform a
fetch to get back in sync.

~~~
adrianpike
That's actually what we're doing right now.

Resource B doesn't always require an update though, and we'd like to be able
to pass back to the client some better information on whether or not that
needs to happen. Unfortunately, I haven't had a brilliant epiphany yet how to
do that without adding some virtual attributes or something similar to the
JSON representation of Resource A that gets passed back.

Thanks for the kind words on our choice of a bunch of technologies - it's most
appreciated. :)

------
disbelief
Great story and congrats on the progress thus far! I have been building an
application using a very similar Backbone+Rails stack, and your decision
making at the top of the article matches up almost identically with mine.

One thing I'm curious about is the performance aspect. When you say
"lightening fast", I assume you're talking about the front-end user
experience, since persistence to the server is performed asynchronously? The
one major problem I've had with using Rails as my JSON API provider has been
the performance of rendering the JSON itself. Many of my API calls return a
fairly large amount of nested JSON, and the request times are far from ideal.

As you mention you are placing additional data into the results for some API
calls, so I guess you might have encountered this yourself.

What, may I ask, are you using to render the JSON from Rails? I'm using
JBuilder at the moment, which as it turns out has some performance issues:
<https://github.com/rails/jbuilder/issues/45>

------
lagartoflojo
I would love to read about how you handled the "modular code" problem. I'm
using Backbone and I find that there are many questions that are left for the
developers to answer. With no conventions, every app starts doing things their
own way, so even if I know Backbone, it might still be hard to work on someone
else's code. Questions are: Where do we fetch data, in the view or in the
controller? Do we keep a central "repository" of data for the whole app to
use, or each widget maintains its own data? On page (re)load, do we favor one
large call to the API or many small ones? How do we structure code in the
filesystem? How do we handle authorization (ex. hiding links or entire modules
from certain users)?

~~~
adrianpike
Painful truth time: We haven't. :(

It's still ugly in there, and while we've been making pretty decent strides
(heyo!), it's not where I'd like it yet. To answer some of your specific
questions/comments though:

\- We're fetching data in the views. We don't really use the Backbone
router/controller concept that heavily.

\- For data, we're exposing everything through a REST-like API exposed from
our Rails app. It's not versioned yet, but we'll be versioning it in the
future. Every Backbone model is responsible for just its own data -
collections are responsible for any extra data that might not belong on a
specific model. Things like client-calculated values, etc.

\- On reload, since we're shoving it out from our Rails app, we're pre-seeding
with some data, but then it fires off a bunch more requests. I don't feel
super strongly that this is the right way, we'll probably experiment with
other options soon.

\- We've got views/ and models/, and the structure's pretty flat inside. It
runs through the Rails pipeline to minify and make a single file, which as of
now isn't CDN'ed.

\- We're not incredibly worried about secrecy for things that aren't enabled
and that users can't see, since our main value prop is still server-side and
under our control. We've got a global User object that we're populating with
flags for what they can & can't see, and their user limitations.

Hope this helped, or if not, at least gave you some stuff to think about. If
you want to chat Backbone sometime, drop me a line!

~~~
lagartoflojo
Thanks for the feedback!

Up until recently, I was a one-man dev "team", so I didn't get a chance to
discuss these topics while developing our app, and I just went with what
seemed right. I'll be thinking about your ideas moving forward. I especially
like the bit about the global User object with flags! (In hindsight, it seems
almost obvious there should be one!)

This fact that every team ends up doing things their own way, and many times
re-inventing the wheel, is the reason why architectures like Marionette and
Aura have appeared. Also coming from Rails, I prefer using a framework that
helps with these decisions up front, so I'm seriously considering moving to,
for example, Ember.js (which was still called SproutCore 2 when I started
developing...). Interesting times ahead though,.. with so much exploration
going on in the Single Page App "arena", it's really hard to tell how things
will end up!

------
theotheo
Hello, guys. For the sake of curiosity, why do you not use Websockets?

