6 ms·

Backbone: Dealing with stateful applications (part 1)

110 points by masylum 15y ago

michokest 15y ago
One of the biggest challenges we found with big Backbone apps is serving templates. Looking forward to hearing how you serve assets from the backend!
- jashkenas 15y ago
  For the record, the approach that we use to serve templates (along with CSS, and JavaScript), is available here: http://documentcloud.github.com/jammit/ http://documentcloud.github.com/jammit/ Just the templating bit: http://documentcloud.github.com/jammit/#jst http://documentcloud.github.com/jammit/#jst ... which allows us to include all of our templates in our JavaScript asset packages by listing them like this: https://github.com/documentcloud/documentcloud/blob/master/config/assets.yml#L20-22 https://github.com/documentcloud/documentcloud/blob/master/c... ... which then means that they'll be served as part of the final, minified, compressed "core" asset package here: http://www.documentcloud.org/assets/core.js http://www.documentcloud.org/assets/core.js (bottom of the file) Or, as a standalone asset here: http://www.documentcloud.org/assets/core.jst http://www.documentcloud.org/assets/core.jst
  - michokest 15y ago
    I was commenting hoping to get others to explain their templating system, honored to see your reply :) This is what we use: https://github.com/teambox/trimmer https://github.com/teambox/trimmer In a nutshell, it takes everything under app/templates and compiles it from Rails (so it has access to I18n and ruby) and serves jades, which we later compile and minify. Trimmer serves the Template and I18n objects, as you can see on this compiled file: https://d238xsvyykqg39.cloudfront.net/assets/trimmer-en-58fced1047f854838c20e20d4d639677.js https://d238xsvyykqg39.cloudfront.net/assets/trimmer-en-58fc... I like that your solution actually packs it together with the rest of the code, avoiding one extra request for templates. Maybe we'll add that to our system too.
- yesbabyyes 15y ago
  This might not be possible for you, but we're running under nodejs and using stitch[1]. It compiles the templates to javascript functions, and we bundle them with all the rest of the javascript as one big file. Simple distribution and awesome performance. [1] https://github.com/sstephenson/stitch https://github.com/sstephenson/stitch
- piranha 15y ago
  What I do is Makefile compiling templates to separate js files for development and for production I combine them using the module system which makes sense - in different projects I had stitch, ender.js and AMD (require.js & seajs).
yesbabyyes 15y ago
This looks like just what I need. I am trying to use Backbone for the first time after eyeing it for a long while, and I'm completely lost as to best practices when it comes to loading and rendering things, either from the router or from a view, and also when it comes to dealing with collections that are part of a model. Here's hoping the next post comes soon!
jashkenas 15y ago
Some of the highlights from the post: * You usually want to avoid having multiple client-side models for a single database row. Keeping your client-side schema close to your database avoids mapping headaches later. * When navigating around, be sure to cancel outstanding ajax requests if the user clicks on another link before the response arrives. * Lazy-loading of associated models is handy, described further here:http://backbonejs.org/#FAQ-nested http://backbonejs.org/#FAQ-nested ... and a few more tips: * You don't need to use an event when a simple callback will do. * In terms of JS apps, Tim Toady is your friend: http://backbonejs.org/#FAQ-tim-toady http://backbonejs.org/#FAQ-tim-toady * You often aren't modeling the complete server-side state in the browser, so look for opportunities to simplify by glossing over data that only concerns the backend.
rorrr 15y ago
Every time I start reading Backbone documentation, my head hurts. This article is even worse. What they need is a simple, to the point, complete examples of apps. There's one that I found that makes some sense to me: http://documentcloud.github.com/backbone/docs/todos.html http://documentcloud.github.com/backbone/docs/todos.html
- joelhooks 15y ago
  Here's a complete app built on Backbone.js: http://weblog.bocoup.com/startup-data-trends/ http://weblog.bocoup.com/startup-data-trends/
- ighost 15y ago
  The Todos example is handy, but not every app is a todos app, and there's plenty of Backbone functionality that is not exercised in this simple app. And when there isn't an existing example of what I'm trying to do close at hand, I find the Backbone docs to be quite good.
  - deleted 15y ago
    [deleted]
- jwarzech 15y ago
  When starting out with backbone.js I also had a difficult time just using the documentation. Backbone is kind of the opposite of other popular MVC frameworks in that its un-opinionated, it doesn't enforce any strict organization which gives more flexibility but also makes it more difficult to learn. What worked the best (however not optimal) for me was to combine the techniques used in the PeepCode(https://peepcode.com/products/backbone-js https://peepcode.com/products/backbone-js) screencasts and Thoughbot's book (https://workshops.thoughtbot.com/backbone-js-on-rails https://workshops.thoughtbot.com/backbone-js-on-rails). Once you start getting in the groove of things the documentation is actually really good for quick look ups and you'll start to see that the framework is actually surprisingly tiny. I also have a couple sample apps up on github that I used to learn backbone if you'd like to see some more examples: https://github.com/jwarzech/inspire_board https://github.com/jwarzech/inspire_board https://github.com/jwarzech/realtime_hn https://github.com/jwarzech/realtime_hn
deet 15y ago
One thing I'd like to see covered in discussing stateful web applications is handling concurrent use and modification of data of data by multiple users or even multiple devices/tabs from the same user. Moving state to the client can result in inconsistencies across clients as each one makes changes. Locking data to prevent this is a usability problem. Pushing changes to the each client is a partial solution, but then you're faced with the users watching the data change in front of them, without any action on their part. This is especially a problem in complex applications with multistep workflows. Perhaps it is outside the scope of this series, since this appears to be focused on the technical aspects of using Backbone rather than application design. But a discussion of patterns that overcome these problems would be very useful.
- karlshea 15y ago
  I think that discussion would be interesting as well. I can almost see some sort of DAG-type (like git) versioning possibly working; or maybe where the only changes that are saved to the store are properties that only one client modified.
  - deet 15y ago
    That's an interesting idea for certain types of applications. It seems as though you would need to specify what groups of attributes need to be modified atomically. Say you have a user model, for example; an address comprised of multiple fields should probably be modified as a unit, but the address and email could be modified simultaneously. This might correspond to how you would logically divide your models anyway. Merges could then be allowed as long as these units are intact. Doing this while maintaining usability seems like a tremendous challenge, however, and I'd love to hear ideas for doing this in a way that's painless for the user, especially when there are dependencies between models.

110 points by masylum 15y ago

One of the biggest challenges we found with big Backbone apps is serving templates. Looking forward to hearing how you serve assets from the backend!

jashkenas 15y ago
For the record, the approach that we use to serve templates (along with CSS, and JavaScript), is available here: http://documentcloud.github.com/jammit/ http://documentcloud.github.com/jammit/ Just the templating bit: http://documentcloud.github.com/jammit/#jst http://documentcloud.github.com/jammit/#jst ... which allows us to include all of our templates in our JavaScript asset packages by listing them like this: https://github.com/documentcloud/documentcloud/blob/master/config/assets.yml#L20-22 https://github.com/documentcloud/documentcloud/blob/master/c... ... which then means that they'll be served as part of the final, minified, compressed "core" asset package here: http://www.documentcloud.org/assets/core.js http://www.documentcloud.org/assets/core.js (bottom of the file) Or, as a standalone asset here: http://www.documentcloud.org/assets/core.jst http://www.documentcloud.org/assets/core.jst
- michokest 15y ago
  I was commenting hoping to get others to explain their templating system, honored to see your reply :) This is what we use: https://github.com/teambox/trimmer https://github.com/teambox/trimmer In a nutshell, it takes everything under app/templates and compiles it from Rails (so it has access to I18n and ruby) and serves jades, which we later compile and minify. Trimmer serves the Template and I18n objects, as you can see on this compiled file: https://d238xsvyykqg39.cloudfront.net/assets/trimmer-en-58fced1047f854838c20e20d4d639677.js https://d238xsvyykqg39.cloudfront.net/assets/trimmer-en-58fc... I like that your solution actually packs it together with the rest of the code, avoiding one extra request for templates. Maybe we'll add that to our system too.
yesbabyyes 15y ago
This might not be possible for you, but we're running under nodejs and using stitch[1]. It compiles the templates to javascript functions, and we bundle them with all the rest of the javascript as one big file. Simple distribution and awesome performance. [1] https://github.com/sstephenson/stitch https://github.com/sstephenson/stitch
piranha 15y ago
What I do is Makefile compiling templates to separate js files for development and for production I combine them using the module system which makes sense - in different projects I had stitch, ender.js and AMD (require.js & seajs).

yesbabyyes 15y ago

This looks like just what I need. I am trying to use Backbone for the first time after eyeing it for a long while, and I'm completely lost as to best practices when it comes to loading and rendering things, either from the router or from a view, and also when it comes to dealing with collections that are part of a model. Here's hoping the next post comes soon!

jashkenas 15y ago

Some of the highlights from the post: * You usually want to avoid having multiple client-side models for a single database row. Keeping your client-side schema close to your database avoids mapping headaches later. * When navigating around, be sure to cancel outstanding ajax requests if the user clicks on another link before the response arrives. * Lazy-loading of associated models is handy, described further here:http://backbonejs.org/#FAQ-nested http://backbonejs.org/#FAQ-nested ... and a few more tips: * You don't need to use an event when a simple callback will do. * In terms of JS apps, Tim Toady is your friend: http://backbonejs.org/#FAQ-tim-toady http://backbonejs.org/#FAQ-tim-toady * You often aren't modeling the complete server-side state in the browser, so look for opportunities to simplify by glossing over data that only concerns the backend.

rorrr 15y ago

Every time I start reading Backbone documentation, my head hurts. This article is even worse. What they need is a simple, to the point, complete examples of apps. There's one that I found that makes some sense to me: http://documentcloud.github.com/backbone/docs/todos.html http://documentcloud.github.com/backbone/docs/todos.html

joelhooks 15y ago
Here's a complete app built on Backbone.js: http://weblog.bocoup.com/startup-data-trends/ http://weblog.bocoup.com/startup-data-trends/
ighost 15y ago
The Todos example is handy, but not every app is a todos app, and there's plenty of Backbone functionality that is not exercised in this simple app. And when there isn't an existing example of what I'm trying to do close at hand, I find the Backbone docs to be quite good.
- deleted 15y ago
  [deleted]
jwarzech 15y ago
When starting out with backbone.js I also had a difficult time just using the documentation. Backbone is kind of the opposite of other popular MVC frameworks in that its un-opinionated, it doesn't enforce any strict organization which gives more flexibility but also makes it more difficult to learn. What worked the best (however not optimal) for me was to combine the techniques used in the PeepCode(https://peepcode.com/products/backbone-js https://peepcode.com/products/backbone-js) screencasts and Thoughbot's book (https://workshops.thoughtbot.com/backbone-js-on-rails https://workshops.thoughtbot.com/backbone-js-on-rails). Once you start getting in the groove of things the documentation is actually really good for quick look ups and you'll start to see that the framework is actually surprisingly tiny. I also have a couple sample apps up on github that I used to learn backbone if you'd like to see some more examples: https://github.com/jwarzech/inspire_board https://github.com/jwarzech/inspire_board https://github.com/jwarzech/realtime_hn https://github.com/jwarzech/realtime_hn

deet 15y ago

One thing I'd like to see covered in discussing stateful web applications is handling concurrent use and modification of data of data by multiple users or even multiple devices/tabs from the same user. Moving state to the client can result in inconsistencies across clients as each one makes changes. Locking data to prevent this is a usability problem. Pushing changes to the each client is a partial solution, but then you're faced with the users watching the data change in front of them, without any action on their part. This is especially a problem in complex applications with multistep workflows. Perhaps it is outside the scope of this series, since this appears to be focused on the technical aspects of using Backbone rather than application design. But a discussion of patterns that overcome these problems would be very useful.

karlshea 15y ago
I think that discussion would be interesting as well. I can almost see some sort of DAG-type (like git) versioning possibly working; or maybe where the only changes that are saved to the store are properties that only one client modified.
- deet 15y ago
  That's an interesting idea for certain types of applications. It seems as though you would need to specify what groups of attributes need to be modified atomically. Say you have a user model, for example; an address comprised of multiple fields should probably be modified as a unit, but the address and email could be modified simultaneously. This might correspond to how you would logically divide your models anyway. Merges could then be allowed as long as these units are intact. Doing this while maintaining usability seems like a tremendous challenge, however, and I'd love to hear ideas for doing this in a way that's painless for the user, especially when there are dependencies between models.