{"id":1127,"date":"2014-10-30T13:25:52","date_gmt":"2014-10-30T11:25:52","guid":{"rendered":"http:\/\/www.webcodegeeks.com\/?p=1127"},"modified":"2014-10-30T13:20:36","modified_gmt":"2014-10-30T11:20:36","slug":"why-should-we-use-server-side-in-backbone-js","status":"publish","type":"post","link":"https:\/\/www.webcodegeeks.com\/javascript\/backbone-js\/why-should-we-use-server-side-in-backbone-js\/","title":{"rendered":"Why should we use server side in Backbone.js?"},"content":{"rendered":"

One of the challenges when building nontrivial Web applications is that JavaScript\u2019s non-directive nature can initially lead to a lack of structure in your code. JavaScript is often written as a free-hanging and unrelated blocks of code, and it doesn\u2019t take long before it becomes hard to make sense of the logic and organization of your own code. This becomes very much problematic when you are making a single page application(SPA). We can use server side scripting along with backbone.js to tackle this problem. Although this very approach creates problems of it\u2019s own.<\/p>\n

In this article we are going to discuss about applying server side scripting to the backbone.js and how to deal with the problems.<\/p>\n

Backbone.js is a Java script framework known as MV* framework. This framework has the Backbone.sync function to perform CRUD (Create, Read, Update, Delete) operations. In order for a model object to perform these operations, it should have a property named \u2018url\u2019. The \u2018sync\u2019 function receives 3 arguments: method, model and options. Model objects also have functions that call the \u2018sync\u2019 functions, these functions are: \u2018fetch\u2019, \u2018save\u2019 and \u2018destroy\u2019. The function Save does both Create and Update operation: If the property id Attribute is defined, and the id Attribute is set, \u2018save\u2019 sends an update request, otherwise it sends a \u2018create\u2019 request. The content type of the request is \u201dapplication\/json\u201d.<\/p>\n

WHY SHOULD WE USE SERVER SIDE IN BACKBONE.JS?<\/h2>\n

Backbone.js is a lightweight framework that addresses this issue by adding structure to\u00a0JavaScript-heavy Web applications.<\/p>\n

Self-contained building blocks<\/strong><\/p>\n

Backbone.js provides several classes (Model, Collection, View, Router) that you can extend to define the building blocks of your application. To build an app with Backbone.js, you first create the Models, Collections, and Views of your application. You then bring these components to life by defining a \u201cRouter\u201d that provides the entry points of your application through a set of URLs.<\/p>\n

Data Binding<\/strong><\/p>\n

With Backbone.js, you bind Views to Models so that when a Model\u2019s data changes, all the Views bound to that Model automatically re-render. No more complex UI synchronization code.<\/p>\n

Elegant REST Integration<\/strong><\/p>\n

Backbone.js also provides a natural \/ magical \/ elegant integration with RESTful services. If your back-end data is exposed through a pure RESTful API, retrieving (GET), creating (POST), updating (PUT), and deleting (DELETE) models is incredibly easy using the Backbone.js simple Model API.<\/p>\n

DIFFERENCE BETWEEN CLIENT AND SERVER SIDE RNDERING:<\/h2>\n

Client-side rendered apps<\/strong><\/p>\n

If you\u2019ve ever built a fully client-side rendered app, you are probably aware of its downfalls: slow loading\/render times, and no useful search engine indexing of your pages.
\nDespite the downfalls, these apps are pretty straightforward to build:<\/p>\n

The backend serves a super-lightweight html page: pretty much an empty \u2018body\u2019 tag with one or so \u2018div\u2019 elements that your JS app dynamically fills in. All of the data rendering happens via client-side templates that are attached as script tags to the html page.
\nThis is great in that your app can get delivered to any JS-capable device and more or less run the same way. Of course, download times of JS bundles, mobile browser fetch order, and the speed of JS processing for your app will vary.<\/p>\n

Server-side Rendered Apps<\/strong><\/p>\n

Here\u2019s an overview of the necessary pieces for approaching a server-rendered app:
\nAs expected, the server actually returns a heavier page to the client. It will consist of html representations of data that would have normally been rendered on the client-side via script-tag templates. Search engine crawlers will actually see the content when they arrive! Instant SEO boosts and a guaranteed increase in organic traffic to your pages. The client won\u2019t have to download your entire JS app, parse and execute it, set up the router, instantiate the proper views and models, fetch the JSON data, and then finally render that data to see a piece of content. The content is all there when the client arrives \u2013 increasing the perceived speed of your page. The backend further utilizes the bootstrap able data that it has available to render more of the page.You now have more of a baseline guarantee as to when users will see your page\u2019s content.<\/p>\n

Although their are some downfalls to this technique also, as depending on how you distribute the responsibilities of your api and html rendering services, your backend has to think about both JSON and HTML-fragment caching. Along with fragment caching, you now have to apply the hard problem of cache invalidation to both your JSON and HTML at the cache. The server also can\u2019t understand the Underscore templates.To recover from this problem we can use node.js.<\/p>\n

Now we have understand a little bit of the upsides and downsides of client side and server side rendering. So, how do we figure out how are our requests will be handled by the server?
\nLet us look through it.<\/p>\n

HOW DOES THE SERVER KNOW WHAT REQUEST TYPE IT RECEIVES?<\/h2>\n

The client-side developer specifies one \u2018url\u2019 only per model. The server-side program can determine the type by checking the value of $_SERVER[‘REQUEST_MOTHED’]:<\/p>\n