HN Explorer

7 comments

[ 2.5 ms ] story [ 28.0 ms ] thread
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. :)

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!

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

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