Rethinking the Single Page Web Application

*
Proposal
Short Form
Intermediate

Excerpt

We were promised a glorious future with RESTful APIs, clients with lighting fast JavaScript engines, and an end to sending UI from the server. Now your project is late, the technical debt is piling up, and you're thinking that hey, Rails wasn't awful.

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.

Description

UnREST: Non-trivial APIs

Consider a user entity in a system, we could represent it as a list:

  • email
  • password

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?

Tags

javascript, rest, architecture, mvc

Speaking experience

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.

Speaker