Overriding Backbone.sync for local use

If you’re using Backbone to develop the front end in a local application you’ll have to override the Backbone.sync functionality to replace the REST functionality normally used by the library. Using Backbone in a local environment to store data, whether to store data in a file on the hard drive or using a local DB, is a bit different from its normal usage. The REST functionality has to be replaced with a file write or some other data storage code. The code below works for me:

Backbone.sync = function(method, model, options) {
    if (method === "create"){
        let attrs = model.changed;
            console.log("Update a record.");
            console.log("Create a record.");
    if(method === "read"){
        if(model.length === 0){
            console.log("Pull the entire collection of records.");
            console.log("Pull a single record.");
    if(method === "delete"){
        console.log("Delete this record and return nothing.");
    if(method === "update"){
        console.log("This update functionality never runs.");
Apache, FlightPHP, Javascript, PHP

Setting up FlightPHP to work with Backbonejs

FlightPHP and Backbonejs work well together inherently by design. Even though the two frameworks are written in two different languages and are designed for different tiers in your enterprise application development design, its hard to ignore the ease of integrating the two.. Most Backbone examples you see posted on the Internet involves node.js on the server; which makes sense considering you program both in javascript. However, the most common (and cheapest) hosting on the Internet is shared host PHP hosting. As long as your load is relatively light you can get really great results out of a shared PHP host as the new PHP runs virtually as fast as C++ on the server (takes about 2x the RAM though).

How Backbone works with FlightPHP

Backbone is a REST-centric library. Basically what that means is that you have to set up four endpoints in your FlightPHP index file for every collection of models in your application. With Backbone, you will not be setting up AJAX calls – the library handles all of the traffic cop stuff for you automatically. Using a Backbone model: a save uses a POST if the model does not have an id set on it from a previous save, and uses a PUT to update the record if it does have an id; a get without and id in the path returns the array of JSON objects (used by Backbone.Collection), including an id in the path returns that record; and a model.destroy uses a DELETE verb to indicate a record delete.

Your CRUD functions will map to the GET, POST, PUT, and DELETE HTTP verbs on your server.

/* basic PHP pseudocode structure for handling backbone CRUD functionality */
// Create
Flight::route('POST /rest/somecollectionname', function($id){
    // posting a new record (saving the model)
        // return the object saved with new id created by db
// Read
Flight::route('GET /rest/somecollectionname(/@id)', function($id){
    // getting a collection or a single record if id was provided
        // return an array of javascript objects or a single
        // object if an id was provided
// Update
Flight::route('PUT /rest/somecollectionname/@id', function($id){
    // updating a record (saving a model with an id)
        // return updated object
// Delete
Flight::route('DELETE /rest/somecollectionname/@id', function($id){
    // deleting a record (destroying a model)

Flight also allows you to map these endpoints to a separate class which is probably the best way to go if you are working on an API that’s larger than a couple of endpoints.

Apache issues – something Node users never have to deal with

On some shared hosts PUT and DELETE requests are blocked by default. You’ll get a 403 Denied error on the first PUT or DELETE attempt if these HTTP verbs are blocked. Its, unfortunately, a fact of life that has to be dealt with. Apache allows PUT and DELETE by default, so its probably the way they have their virtual hosts configuration set (usually because of security issues). You can sometimes (probably) get away with a .htaccess directive to overcome this shortfall. Other than that I recommend you contact whatever host you have for a solution.

# try this in .htaccess
order deny,allow
allow from all

Even if your shared host vehemently denies you access to these verbs, a workaround is relatively easy to script. For instance: add an updateid to your model to indicate an update and handle it as a new record on the client, etc. It shouldn’t come down to that though (a paying customer is a paying customer).

If you are running your own server you should open “/etc/httpd/conf/httpd.conf” as root and look for something that looks like:

<Directory /home/*>
AllowOverride All
Options -MultiViews -Indexes FollowSymlinks IncludesNoExec +Includes
Order allow,deny
Allow from all
Order deny,allow
Deny from all

Anywhere you see “GET POST” just add put and delete : “GET POST PUT DELETE”. Then restart httpd server with “/sbin/service httpd restart” and they should work. Also, here is a link to a good how-to for Apache in case you get confused:
Apache Docs

In many cases you might not even need those two verbs. Many people use Backbonejs to display and sort data on the client without ever needing to use PUT or DELETE.