In the previous post, I showed how you can create a minimal server that proxies requests on to Parse.com for back-end data storage.
Next, I need to consider the Backbone.js side of things. Backbone gives a really great way of describing models and collections as long as the data conforms to its REST flavor. Unfortunately, Parse.com does things a little bit differently. I have encapsulated this code into some base prototypes that can be used later.
class Backbone.ParseCollection extends Backbone.Collection parse: (resp, xhr) -> data = super data.results fetch: (options) -> if options?.query? options.data = "where=" + JSON.stringify options.query delete options.query super class Backbone.ParseModel extends Backbone.Model setId: (data) -> data.id = data.objectId unless data.id data constructor: (model) -> @setId model super parse: (resp, xhr) -> @setId super toJSON: () -> result = super delete result.createdAt delete result.updatedAt result
These base classes help me to adapt the data and behavior of Parse.com:
Backbone wants a JSON array from the server. Parse.com gives you a JSON object with an array called “results” inside the root object. The code overrides Backbone.Collection.parse to return the array property from the Parse.com response.
You can make server-side queries via the query parameters in the Parse.com API. The code overrides Backbone.Collection.fetch to take a “query” option. Mutate it to the format that Parse.com wants in the API. I’ll discuss this more in the next post.
Parse.com IDs have the name of “objectId” but Backbone expects the IDs to be named “id”. The code overrides the Backbone.Model.parse and Backbone.Model.constructor functions to set the ID based on the “objectID” that comes from Parse.com. This will be used later when updating or deleting the object.
Parse.com includes two metadata fields: “createdAt” and “updatedAt”. While they may be useful, Parse.com fails if you send these fields via a PUT request. The code overrides Backbone.Model.toJSON to remove these items from the serialization, thus keeping them from being sent to Parse.com as well.
We now have base prototypes that allow us to communicate with the server. Instead of extending Backbone.Model and Backbone.Collection, you should make your models extend Backbone.ParseModel and Backbone.ParseCollection.
In the next post, I will show how to do this and we will play in the browser a bit in order to show how Backbone.js models and collections interact with the proxy server.