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.
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.
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.
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.