Should Backbone Model represent a view or a server-side resource?

Question

Assume a situation where I've a Rails AR models as below

class User
  has_one :profile
end

class Profile
  belongs_to user
  has_one :address
end

class Address
  belongs_to :profile
end

And have a User Profile view to be constructed at the client-side. Now, how should my Backbone model look like? Should it replicate the way it is in Rails/server-side domain model? Do we have a clear reason for the way it has to be that way, or is it just subjective?

Your experience sharing is appreciated!

Answer 1

Usually your backbone models and collections should follow your REST API ( or any other client-side <-> server-side communication ).

1. For example if these ruby models are passed to the frontend with :

   GET /api/user/:id
   

   And what you got as a response is

   [{ profile: { address: "21st str." } },{ profile: { address: "17th str." } }]
   

   You would need one model

   User = Backbone.Model
   Users = Backbone.Collection.extend({
      model: User,
      url: "/api/user"
   });
   

2. But if you do something more complicated in your API and have more urls in your API you could choose the structure that best fits your interaction with the client on your frontend. For example if your website doesn't need a user api at all and you pass data to the frontend with those urls:

   GET /api/profile
   

   You can have only one model

   ProfileModel = Backbone.Model.extend({
       url: "/api/profile"
   })
   

   And you can easily set the address like

   profile = new ProfileModel();
   profile.set('address', '21st str.');
   

Bottom line

Backbone usually should follow your URL structure of your REST API. If you do this you will enjoy the full benefits of using it's REST Ajax calls ( GET, POST, DELETE, PUT ) properly autoconfigured.

Usually what I don't do is to make my Backbone app structure to follow the database schema. That may cause a headache, because you will need to create a way your backend ( Ruby app ) to be able to provide almost the same database access as the ORM that you are using.