How we used Rails & Backbone.js to build a lightning-fast webapp.
adrianpike.tumblr.com
adrianpike.tumblr.com
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
}); 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. :)
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
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!
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!