Develop Reference

Creation of backbone views/models based up on server side Objects' structure

While creating Backbone Models and Collections for a web page, I feel the data can be segregated as models and collections in multiple ways.
Consider an example where I have a web page and ideally I should create one backbone view and there by one backbone model for that view. However, the data has to go in to two different data base tables at server side. In these kind of situations, I get confused whether I should just consider the front end scenario while defining view/models or should I just create them based up on the server side POJO classes structure.
I mean, If I just think from front end perspective, I just need to create one backbone view and one model. However, if I think from server side Object's perspective, I need to create two backbone views and two models.
Could someone please tell me what are the things to be considered while dividing a page as different backbone views and models and kindly provide any references

This depends on your REST API.
Backbone does not directly interact with backend tables, it usually uses a REST API that interacts with the tables (or whatever data storage).
If the API has endpoints for performing CRUD operations directly on a table, then you should create a backbone model client side representing it, and use it's built in methods such as save(), destroy() etc to interact with the REST API.
If your rest API returns data which is the result of joins of multiple tables, has single end points that updates multiple tables on backend, then it makes sense to have a model containing data from all those tables, and interact with the REST API using built in methods which updates all these tables accordingly.
So in short, you should create the frontend models according to the REST API, not directly according to the database structure.

With Reflux, 2 stores or 1 store for a resource? (Bikes/CurrentBike vs Bikes)

I'm still trying to wrap my head around frontend state. Is there a common best practice for setting up stores for a resource? For example, my web api has:
GET /bikes
GET /bikes/:id
I started off with just a BikeStore and bikes: []. Now I'm working on the ShowBike component and not sure if I should use the BikeStore (not exactly sure how) or make a second store for single items.

The store concept in Flux is rather simple abstraction on the client how you get access to the data. Separate stores should be used for different kinds of data. In your case the resource is the same, there is not any good reason to keep separate stores for bikes. Even more: stores for single items is not an intended usage and should be avoided.
From the flux docs:
Stores contain the application state and logic. Their role is somewhat similar to a model in a traditional MVC, but they manage the state of many objects — they do not represent a single record of data like ORM models do. Nor are they the same as Backbone's collections. More than simply managing a collection of ORM-style objects, stores manage the application state for a particular domain within the application.

creating new entities in Backbone Marionette for related models

I've built the backbone app with one model ("conference"). Now I added second model ("talk"). talks belongs to conference, conference has many talks. The nested json is created and it is easy to render it into single-conference template with .eco like this:
I can basically build nested json and render nested attributes, no problem but is it a good architecture? Later it will have more layers , every talk will have many comments. What I should do?
Should I build new entities "talks" and use Backbone - associations?
What is the right way to deal with models relations.
My code is based on backboneonrails tutorial and it is very structured: https://github.com/lipenco/talkingheads
I want to maintain good architecture while going into related models.

It's not good to store objects in model's attribute. You can have problems with 'change' event not triggered if you change value of properties in attribute that is object.
So I think it's better to create separate model for talk. You can do all association work manually or use library for that: http://backbonerelational.org/

Is AngularJS really MVC?

I'm looking through examples on the AngularJS home page — specifically “Add Some Control”. I don’t quite understand how it maps to MVC pattern.
It’s more or less clear that the template (index.html) can be thought of as the view, objects constructed by TodoCtrl from todo.js as the controller, but where is a model? Attributes like ng-model map to some internal pieces of the framework and don’t directly expose an object which we could call a model.
Is it correct to call AngularJS an MVC framework?

The core idea behind MVC is that you have clear separation in your code between
managing its data (model), the application logic (controller), and presenting the data
to the user (view).
The view gets data from the model to display to the user. When a user interacts with the
application by clicking or typing, the controller responds by changing data in the model.
Finally, the model notifies the view that a change has occurred so that it can update what
it displays.
In Angular applications, the view is the Document Object Model (DOM), the controllers
are JavaScript classes, and the model data is stored in object properties.

I havent read up on Angular. However, keep in mind that "true" MVC means that the Model contains business Logic, the Controller takes care of communicating user input to the Model, and the View gets its own data from the Model. Many so called MVC frameworks are actually not implementing MVC the right way: They are overloading the Controller With to much responsibility, as in making the Controller responsible also to update the View. That is not what the Controller was intended to do, and in such cases you get what is called a "fat Controller". There is a misconseption among many webdevelopers that the View is simply a "template". This is both true and false; It is a template but it get its own data directly from the Model - not via the Controller.
But as I started out saying: I havent yet read up on Angular, but you might have so yourself and you should be able to find out if Angular is truly a MVC framework by looking at what the different Components in the Framework does.

The attributes map into the scope variable as defined in the controller. For example, if you have some JS objects which represent your business logic, you can put those in the scope variable, and then the attributes can be mapped into the model itself instead of some arbitrary values in the scope variable.

If anything that can store data in a object is considered a model than every front end framework (view) could be considered to have a model. They can all store data in objects and present them in the view. I think calling angular a mvc is really a marketing ploy, trying to make angular seem like it is more than it is.
See:
https://www.pluralsight.com/blog/software-development/tutorial-angularjs-mvc-implementation
In the controller, is where they give their example of angular's as a model. If it can't assist in the storage of persistent data it isn't much of a model.

Backbone.js - What is the best approach for global/shared/related models?

I'm currently building an application using Backbone.js with a number of different models that all relate to each other in various ways. I'm currently experimenting with various architectural approaches.
In a nutshell the model relationships looks something like this:
Workspace > Projects > Tasks
There are a few other models, such as lists and categories, that are attached to a project.
On a page with a task list, I'm dumping the JSON of the tasks onto the page and filling up the collection. This works ok, but at the moment all tasks are pulling in their own project data.
task.project.id
task.project.name
The projects are also being pulled in various other locations on the page for various lists. Tasks can also be part of a List which is assigned to a Project. This means I'm also making requests to pull in the lists for a project in various places as well.
The main problem with this is that when updating a model in place I need to find some way to 'sync' them. Which is crazy. They should all be using the same model instance so that each view is using the same model and is updated accordingly without having to do anything.
I've been researching various Backbone.js architectural designs to try and find the answer. Chaplin (https://github.com/moviepilot/chaplin), for example, uses a mediator object to pass data between views. Using this approach, I could have a Projects collection on the mediator and pass this around to the various views via the mediator object.
Each project would include all of it's lists, categories, assigned users etc. Then I could request for a project model like so:
App.Projects.get(12)
Then the task would just need the project ID and a getter and setter method. Views could get access to available projects, project lists, project users easily as well without relying on digging into the model or making further AJAX calls. Additionally, the task models wouldn't require any of the project data on them.
However, dumping all this data in a global object seems bad.
I would possibly end up with something like this:
App.Workspaces
App.Workspaces.get(1)
App.Projects
App.Projects.get(12).get('lists')[0]
App.Projects.get(12).get('users')
To use like this:
var projectId = model.get('project')
var project = App.Projects.get(projectId)
Or with a getter method:
var project = model.getProject()
And add the mediator as a dependency at the model level instead.
Adding a large global object like this adds a fairly large dependency that could make testing difficult. It also seems wrong to assume that the mediator will even have the project available. Maybe it could make the model, fetch it and return it if it doesn't exist.
Any help here would be great! I'd love to know how other people have solved this problem.

I recommend to have a common Collection for all your Task Models. Kind of cache.
Something like: App.Store.Tasks.
Any time you need to feed the Poject.Tasks look first in the App.Store.Tasks and then:
A. If you found the Task there then take it and add it to your Project.Tasks.
B. If not found there then create, fetch and add it to both: App.Store.Tasks and your Project.Tasks.
This way other Project that tries to fetch a Task that already exits will do the same and they both will share the same Model.
Any time you modify one of your Task models in a Project you'll be modifying this Task in every other Project.