“The evolution of JavaScript, CSS, and HTML makes SPAs much more powerful ways to build an application. Full-featured data APIs, standardized protocol for creating and consuming data using OData”

 “To design the future effectively, you must first let go of your past. Because an ounce of performance is worth pounds of promises.”

  – Praveen Kumar G


Every time you use Gmail, Google Plus or Facebook, you are using Single Page Application (SPA). SPA provides rich user interface and high experience in navigation between the pages within a single page. SPA provides best performance applications with high responsive designs and intutive platform for mobility.

Why SPAs?

The main reason is that they allow us to offer a more-native-app-like experience to the user. This is hard to do with the other approaches. Supporting rich interactions with multiple components on a page means that those components have many more intermediate states. Single page apps are distinguished by their ability to redraw any part of the UI without requiring a server roundtrip to retrieve HTML. Which in turn reduces the number of hits to the server and increases the application’s load time.

MVC (Razor) vs MVVM (SPA)

The native application development like MVC/Razor (Model-View-Controller) is a server based technology whereas SPA is an Architecture approach used on client web browser with Model-View-View-Model approach.

From a high level, SPA moves the rendering and data retrieval to the client. The web server becomes a services tier sitting in front of the database. An MVC pattern tweaked to MVVM to work best using SPA. Frameworks like Knockout.js and Backbone.js can be used for this approach to bind the data tier to the application.

Reducing the network load with SPA improves the server side performances when compared to the earlier native applications. This is achieved by separating the data from the presentation of data by having a model layer that handles data and a view layer that reads from the models.

Modern Application Development

Most projects start with high ambitions, and an imperfect understanding of the problem at hand. Our implementations tend to outpace our understanding. It is possible to write code without understanding the problem fully; that code is just more complex than it needs to be because of our lack of understanding. The architectures used in single page apps represent the result of this process, where we would do things in an ad-hoc way using jQuery.


Write-Only DOM Approach

No state / data is read from the DOM. The application outputs HTML and operations on elements, but nothing is ever read from the DOM. Storing state in the DOM gets hard to manage very quickly: it is much better to have one place where the data lives and to render the UI from the data, particularly when the same data has to be shown in multiple places in the UI.

View Observer Model Changes

We want the views to reflect the content of the models. When multiple views depend on a single model, we don’t want to manually keep track of each dependent view. Instead of manually tracking things, there is a change event system through which views receive change notifications from models and handle redrawing themselves.

Decoupled Modules

Decoupled modules that expose small external surfaces. Instead of making things global, we should try to create small subsystems that are not interdependent. Dependencies make code hard to set up for testing. Small external surfaces make refactoring internals easy, since most things can changes as long as the external interface remains the same.

Minimizing DOM dependent-code

Any code that depends on the DOM needs to be tested for cross-browser compatibility. By writing code in a way that isolates those areas, a much more limited surface area needs to be tested for cross-browser compatibility. Cross-browser incompatibilities are a lot more manageable this way. Incompatibilities are in the DOM implementations, not in the Javascript implementations, so it makes sense to minimize and isolate DOM dependent code.

No Controller Approach

Instead of writing too many server side MVC, SPA provides the placeholder technique to avoid the response with the DOM events. Controllers deal with adding and responding to DOM events, rendering templates and keeping views and models in sync, this is improved through SPA.



Querying data with OData Services

The Open Data Protocol (OData) is a data access protocol for the web. OData provides a uniform way to structure data, query the data, and manipulate the data set through CRUD operations (create, read, update, and delete). OData supports both AtomPub (XML) and JSON formats. OData also defines a way to expose metadata about the data. Clients can use the metadata to discover the type information and relationships for the data set.


A standard web services enables us to create some functions or procedures that returns or update data. The base idea is that, we enable consumers to access these functions via web using HTTP protocol. This is base for the service-oriented architecture (SOA). SOA can never predict what kind of queries/services will be required by our consumers, therefore we will always need to add new services, add parameters or return values to existing services just because some consumer need something specific.

Another approach is so called resource-oriented architecture (ROA) where we expose resources and enable users to run various ad-hoc queries against the resources. This is similar to the approach in the database systems where we have tables that represent data and ability to create various SQL queries. The only difference is that in ROA we create queries via URL.

OData is a protocol that specifies characteristics of web services that exposes data and can implement web services compliant to this protocol using the WCF Data Service technology. The basic idea is that we can open some URL with parameters that will execute queries against the resources with dynamic query approach. OData also provides formatting of data to support with JSON as well as XML.