CODEWITHSUNDEEP
restbackbone.jswebsocket
user1491636
user1491636

Reputation: 2436

Non-RESTful backend with backbone.js

I'm evaluating backbone.js as a potential javascript library for use in an application which will have a few different backends: WebSocket, REST, and 3rd party library producing JSON. I've read some opinions that backbone.js works beautifully with RESTful backends so long as the api is 'by the book' and follows the appropriate http verbage. Can someone elaborate on what this means?

Also, how much trouble is it to get backbone.js to connect to WebSockets? Lastly, are there any issues with integrating a backbone.js model with a function which returns JSON - in other words does the data model always need to be served via REST?

Upvotes: 2

Views: 623

Answers (1)

Toli
Toli

Reputation: 5777

Backbone's power is that it has an incredibly flexible and modular structure. It means that any part of Backbone you can use, extend, take out, or modify. This includes the AJAX functionality.

Backbone doesn't "care" where do you get the data for your collections or models. It will help you out by providing an out of the box RESTful "ajax" solution, but it won't be mad if you want to use something else!

This allows you to find (or write) any plugin you want to handle the server interaction. Just look on backplug.io, Google, and Github.

Specifically for Sockets there is backbone.iobind.

Can't find a plugin, no worries. I can tell you exactly how to write one (it's 100x easier than it sounds).

The first thing that you need to understand is that overwriting behavior is SUPER easy. There are 2 main ways:

Globally:

Backbone.Collection.prototype.sync = function() { 
   //screw you Backbone!!! You're completely useless I am doing my own thing 
}

Per instance

var MySpecialCollection = Backbone.Collection.extend({
    sync: function() { 
       //I like what you're doing with the ajax thing... Clever clever ;)
       // But for a few collections I wanna do it my way. That cool?
});

And the only other thing you need to know is what happens when you call "fetch" on a collection. This is the "by the book"/"out of the box behavior" behavior:

  1. collection#fetch is triggered by user (YOU). fetch will delegate the ACTUAL fetching (ajax, sockets, local storage, or even a function that instantly returns json) to some other function (collection#sync). Whatever function is in collection.sync has to has to take 3 arguments:
    1. action: create (for creating), action: read (for fetching), delete (for deleting), or update (for updating) = CRUD.
    2. context (this variable) - if you don't know what this does it, don't worry about it, not important for now
    3. options - where da magic is. We only care about 1 option though
      • success: a callback that gets called when the data is "ready". THIS is the callback that collection#fetch is interested in because that's when it takes over and does it's thing. The only requirements is that sync passes it the following 1st argument
      • response: the actual data it got back
    4. Now has to return a success callback in it's options that gets executed when it's done getting the data. That function what it's responsible for is
  2. Whenever collection#sync is done doing it's thing, collection#fetch takes back over (with that callback in passed in to success) and does the following nifty steps:
    1. Calls set or reset (for these purposes they're roughly the same).
    2. When set finishes, it triggers a sync event on the collection broadcasting to the world "yo I'm ready!!"
  3. So what happens in set. Well bunch of stuff (deduping, parsing, sorting, parsing, removing, creating models, propagating changesand general maintenance). Don't worry about it. It works ;) What you need to worry about is how you can hook in to different parts of this process. The only two you should worry about (if your wraps data in weird ways) are
    1. collection#parse for parsing a collection. Should accept raw JSON (or whatever format) that comes from the server/ajax/websocket/function/worker/whoknowwhat and turn it into an ARRAY of objects. Takes in for 1st argument resp (the JSON) and should spit out a mutated response for return. Easy peasy.
    2. model#parse. Same as collection but it takes in the raw objects (i.e. imagine you iterate over the output of collection#parse) and splits out an "unwrapped" object.
  4. Get off your computer and go to the beach because you finished your work in 1/100th the time you thought it would take.

That's all you need to know in order to implement whatever server system you want in place of the vanilla "ajax requests".

Upvotes: 6

Related Questions