Rethinking the Single Page Web Application*
Let's talk about when it's a good idea to build a single page, client side app, and when it's not. I'll be drawing from my experience building a single-app to manage an enterprise software as a service product.
Before you jumped into Backbone, Ember, or Angular, you needed to think through the APIs you have, and still had to build. You need to look at the interactions in your UI. You need to figure out where and how your users will access the application.
UnREST: Non-trivial APIs
Consider a user entity in a system, we could represent it as a list:
But users aren’t much use unless they can do things. We need to assign users to groups of entities they can do things with.
But a group isn’t a user.
You have two API endpoints:
/user(/NN) and /group(/NN)
I can create a new user by posting a email and password to /user.
But to associate a user to a group, we have to PUT the user to the group API.
And you are correct in saying, “but shouldn’t the user object have associated groups as a property?”
Yes it would make sense, but the API engineers don’t have the bandwidth to change it, and we really got to get this feature done.
So now, in order to create a user, I have to make at least two requests. One to create the username and password, and multiple requests to the group API to associate the user to groups.
What happens when one of those requests fail?
Most recently I gave a talk at YAPC:NA 2013, http://www.youtube.com/watch?v=jEzgzMzgekU on building single-page apps using Perl and Backbone.
Bill writes software, worries about identity and privacy, and is still trying to balance simplicity vs. shipping a product.