Cross-domain Requests

In developing web applications it’s commonplace to send and receive data
to APIs (Application Programmable Interfaces) that exist on other
domains. This cross-domain communication is often performed directly in
the browser, on the client-side using JavaScript. Cross-domain
communication can be accomplished using a server-side languages like
Python, Nodejs, PHP, etc., however for cases where responses from
cross-domain requests are utilized in the browser, JavaScript can save
time and simplify development. Addintionaly, JavaScript requests are
asynchronous— meaning they can be run in parallel with other processes.
For example, JavaScript requests to other domains can be processed
asynchronously while the page is still loading.

Same-origin Policy

Same-origin policy is an important security concept in client-side
programming languages including JavaScript. This policy is observed by
all web browsers and limits scripts running on a site to only sending
requests with the same site. Browers use a combination of port number
(e.g. 80) and hostname (e.g. my.domain.com) to determine the scope of
the ‘site’. There are however exceptions to the same-origin policy,
including using the HTML <script> tag to retreive a dynamically
generated JavaScript file from an external site. The most prominent of
method of exploiting this exception is JSONP.

JSON with Padding (JSONP)

JSONP uses the <script> tag to retreive remote JavaScript code
containing formatted JSON data with a function call wrapped around it.
The data is not parsed, rather it is evaluated by the JavaScript
interpreter.

The “padding” in JSONP refers to the function call that wraps the
formatted JSON object. This padding isn’t always a function call. Though
not common, padding could also be a variable assignment:

vardata={"id":"123","comments":"6","name":"sample"};

The purpose of the padding is to allow a means for the formatted data to
be put to use in the application.

jQuery for JSONP

The jQuery JavaScript library has functions to make using JSONP a
snap.jQuery’s
$.ajax() function
will automatically handle <script> tag injection and response
handling (i.e. calling the ‘callback’ function).

$.ajax({//JSONP APIurl:"http://remote.domain.com/data/?callback=jsonpcallback&id=123",//the name of the callback functionjsonp:"jsonpcallback",//tell jQuery to expect JSONPdataType:"jsonp",//tell YQL what we want and that we want JSONdata:{id:"123"},//work with the responsesuccess:function(data){console.log(data);//formatted JSON data}});

console.log(data);

{"id":"123","comments":"6","name":"sample"}

Alternatively, if jQuery is not available- which is often the case when
developing embeddable widgets- raw JavaScript can be used. The following
is minimal JSONP implementation:

What does “bootstrapping” mean exactly? Hard-coding your data to the
page using synchronous server-side template.

Most developers face the challenge of sending data from their
server-side to the client-side to be used JavaScript. There are several
solutions for this. Among the most common is creating an REST endpoint
that can be consumed with asynchronous javascript, often using the
jQuery Ajax function.

How is page load time affected when loading data asynchronously?
Does the user’s experience depend directly on this data?

Is there unecessary overhead creating an REST endpoint?

Does the REST endpoint need to be secure? Authenticated? CSRF
Tokenized?

Depending on the answers to these questions, bootstrapping may be an
elegant solution for getting the data to the client-side quickly and
with minimal development.

Note: it’s best to put the bootstrapped object near the top of the page
so it can used immediately, even before remaining html/css/javascript is
loaded.

The key benefit of the bootstrapped object comes in the time saved when
not having to use asynchronous JavaScript to call data from a REST
endpoint. If you typically use jQuery Ajax to do this, 100-500
milliseconds of prerequsite load time would be added just to gain access
to the jQuery.ajax() function. Any ajax request(s) retreiving data
from a REST endpoint comes with additional load time expense.

If your app depends on this data, synchronously loaded (aka
“bootstrapped”) JSON data will make your app snappy and your users
happy. Not to mention, because of the server-side templating, REST
endpoint security considerations are nullified.

The use of nested JSON object often allows developers to break out of the common relational schemas employed in databases like MySQL and MSSQL. When not limited to a shallow data schema based on rows and columns, data can take on new strucutres to better align with development needs. When JSON is used in a persitence layer, nested objects can often be used to replace simple relationships that might have existed in a relational data schema.

Nested JSON Object

Nesting like this can greatly simplify data storage and make data more easily digestible and traversible by an app. Unlike data stored in rows and columns, JSON can be structured to be infinitely deep. Objects can be nested inside objects, nested inside objects, etc..

Relational Database Structure

A similar dataset to the above might look like the following in a relational data schema:

employee_skill [table]

In this case, to define the relationships between skills and employees we’re forced to use three tables, each with a rigid structure. The cost-benefit of JSON is evident, especially if data storage requirements ever change. Imagine the cost of maintaining 3 tables versus one flexible JSON object. Not all data is suited for JSON. For those who value maintainability and flexibility over rigid schemas, it’s a fantastic alternative—one increasing greatly in popularity.

JSON is a attractive option for setting up a custom analytics data store. The flexibility of JSON allows for website owners flexibly store data and get creative in changing tracked data over— all without worring about changing a database schema.

Here’s an example of what an object containing analytics data might look like:

Notice some fields are prefixed with an underscore— these denote ‘default’ fields while fields without an underscore are considered ‘custom’ fields. This allows as to create extend our JSON objects, while still providing the bare minimum defaults that would be used in an analytics application. Say for example, in one month of implementing analytics tracking, business requirements change and now it’s important to track a new field ‘widget_type’. Without making a change to a database schema (common with relational databases), we can add the ‘widget_type’ field to analytics object and save.

Over time as tracking requirements broaden, the size (and number of fields) in your analytics objects scales infinitely to meet. When these objects are stored with a great DBAAS (DataBase As A Service) like
a(href=”http://cloudant.com”) cloudant.com
data can be easily mined for interesting patterns and returned to a dashboard for further visualization. Many web-based data visualization libraries use JSON natively, so starting in this format will be an additional time-saver.