Heuristic for dividing front-end and back-end logic in libraries like backbone.js

Question

am new to learning about MVC.

I am wondering if there is a heuristic (non programatically speaking) out there for dividing and deciding what logic goes on the front-end as opposed to the back-end especially when using front-end libraries like backbone.js.

That is, libraries like backbone.js separate data from DOM elements which makes it useful for creating sophisticated client side logic that, perhaps, used to be carried out on the server side.

Thanks in advance Joey

Answer 1

The "classic" way to do Model - View - Controller is to have all three on the server. The View layer output of HTML and some JS is then rendered by the browser.

Rails is an excellent example of this.

The "new cool" way is to treat the browser as the main computing engine with the backend server providing services via APIs.

In this case, the Model, View and Controller software all run (as Javascript or coffeescript) on the client. Backbone is often a part of the browser-side solution but it has alternatives such as spine, angularJS and others.

On the backend server, you run the dbms and a good API system. There are some good frameworks being built on Ruby/Rack. See posts by Daniel Doubrovkine on code.dblock.org You have many choices here.

Advantages of MVC on the client

• Responsive user interface for the user
• Cool Ajaxy single page effects
• Single page webapps can provide much faster UI to user than regular web sites
• Good architecture, enabler for purpose build iPhone/Android apps
• Depending on the app, can be used to create standalone webapps which work without a network connection.
• This is what many cool kids are doing these days

Disadvantages

• Need to decide on approach for old browsers, IE, etc
• Making content available for search engines can be tricky. May require shadow website just for the search engines
• Testing can be a challenge. But see new libs such as AngularJS which include a testability focus
• This approach involves more software: takes longer to write and test.

Choosing

It's up to you. Decision depends on your timeframe, resources, experience, needs, etc etc. There is no need to use backbone or similar. Doing so is a tradeoff (see above). It will always be faster/easier not to use it but doing without it (or similar) may not accomplish your goals.

You can build a great MVC app out of just Rails, or PHP with add-on libs or other MVC solutions.

Answer 2

I think you're using the word heuristic in a non-programmatic sense correct? I.e. you're using it to mean something along the lines of 'rule of thumb'?

As a rule of thumb:

• You want the server to render the initial page load for UX and SEO reasons.
• You could also have subsequent AJAX partial page loads rendered by the server for the same reasons. Profile to see which is faster: having the server render and transfer extra data (the markup) over-the-wire vs. sending a more concise payload (with JSON) and having the client render it. There are tradeoffs especially if you take into consideration mobile devices where maybe rendering on the client will be slower, but then again there are mobile devices out there with slower internet connections...
• Like any client-server architecture: You want the client to do things that require fast responsiveness on the client and then send some asynchronous operation to the server that performs performs the same task.

The take away is vague, but true: it's all about tradeoffs and you have to decide what your products needs are.

Answer 3

The first two things to come to mind for me were security & search..

• You will always want to restrict read/write access on the server.
• in most instances you will want to have your search functionality as close to the data as possible.