You should now be fairly comfortable working within the Node.js ecosystem of modules, tasks, and package management. In this chapter, we will dive a bit deeper into the intricacies of a JavaScript SPA and its dependencies. We will explore various data formats and database types, SPA encapsulation architectural patterns, and more through the following topics:
- JSON and other data formats
- The differences between SQL and NoSQL databases
- When to use SQL versus NoSQL databases
- Methods of presenting a single page application container
- Serving and managing layouts
JavaScript Object Notation (JSON) is something that most JavaScript developers today are quite familiar with. Despite its name, JSON is a language-independent standard that is really just a text document, and it must first be parsed by JavaScript, or any language interpreter, before it can be used as data representing objects with name-value pairs, or as simple sequences of values.
The reason the JSON acronym includes the word JavaScript is because its formatting is based on the structure of JavaScript objects and arrays. This is why working with JSON data and JavaScript is so straightforward, and why it makes a lot of sense to consume JSON data from within JavaScript applications.
The contents of the user.json file we created in
Chapter 2
, Model-View-Whatever is an example of the JSON data interchange format:
{
"id": 1,
"name": {
"first": "Philip",
"last": "Klauzinski"
},
"title": "Sr. UI Engineer",
"website": "http://webtopian.com"
}
JSON follows the format of standard JavaScript objects, but must also adhere to a few important rules to be valid:
- Property names must be formatted as strings in double quotes
- A value can be a string in double quotes, a number,
trueorfalse, an object, or an array - Objects and arrays can be nested
- Double quotes contained within a string must be escaped using backslashes
These rules allow the JSON format to be parsed directly to native JavaScript while still being strict enough to make it an easily interchangeable format across languages. Although native JavaScript object notation does not enforce the use of double quotes around property names, it is required for JSON in order to prevent JavaScript reserved word exceptions from occurring.
Reserved words in JavaScript are not allowed to be used as variable or function names because they represent some current or potential future construct of the language. For example, the reserved word class is often misused by inexperienced developers as a variable name for holding a CSS class:
Var class = 'myClass';
This example would throw an exception because class is a reserved word. Additionally, using it as a straight property name in a JavaScript object would throw an exception:
{
class: 'myClass'
}
An experienced JavaScript developer would know not to use this word as a property name due to it being a reserved word, but if your application is consuming JSON data from an external source, you have no control over the property names that may be pulled in with an object. For example, you may retrieve data from an application running on another server that is not JavaScript and has no awareness of the reserved word restrictions of any other application that may consume it. If this application wants to convey CSS class information, it is likely that it may use the word "class" to do so:
{
"class": "myClass"
}
In this example, the property name is valid because it is in double quotes and thereby parsed as a string instead of as a reserved word. For this reason, the rule requiring double quotes around property names is strictly enforced, and no JSON parser will allow property names without them.
JSON was first conceived of in 2001 by Douglas Crockford. Before then, data interchange had long been a practice using established formats that were already integrated with many programming languages.
Long before JSON was commonly known, Extensible Markup Language (XML) was one of the most widely used web application data interchange formats. XML was first introduced in 1996 and would become an international standard. It is a form of Standard Generalized Markup Language (SGML) and was created by the World Wide Web Consortium (W3C):
<?xml version="1.0" encoding="UTF-8"?>
<note>
<to>Tobums Kindermeyer</to>
<from>Jarmond Dittlemore</from>
<heading>A Message</heading>
<body>Hello world!</body>
</note>
This is a simple example of a XML document. If you haven't worked with XML before, you most likely have at least heard of it. XML was a precursor to many other data formats, including SOAP, RSS, Atom, and XHTML. XHTML is also well known to many web developers, and it was the recommended standard for serving web pages before the HTML5 specification was introduced. Notice that the formatting of the preceding example is similar to HTML.
YAML is a recursive acronym, meaning it refers to itself, for YAML Ain't Markup Language. What makes YAML interesting, aside from its silly name, is that its syntax for hierarchy requires the use of lines and indentation as delimiters, rather than structured enclosures such as curly braces and brackets, which are used in JSON:
item-key-one: - list item 1 - list item 2 item-key-two: nested_key_one: this is an associative array nested_key_two: end the associative array
The syntax for YAML was designed to make the hierarchy structure of data more easily human-readable by requiring the lines and spaces for explicit delineation of its structure. In contrast, other data formats that use characters such as brackets for defining structure can find it difficult to convey hierarchy to the human eye, especially when in compressed format.
YAML was first created around the same time as JSON, but it has not received nearly the amount of notoriety that JSON has in the web development community. YAML is arguably more flexible than JSON in that it allows for more features, such as comments and relational anchors, but it is likely the simplicity of JSON that makes it a more popular data format for consumption within web applications and beyond.
Binary JSON (BSON) is a binary form of JSON that is used primarily as the data storage format for the MongoDB document-oriented database system. BSON is just like JSON, with the main difference being that BSON supports more complex data types such as Date, Timestamp, and ObjectId. An ObjectId in BSON and MongoDB is a 12-byte unique identifier for a stored object. MongoDB requires that every object has a unique identifier field named _id and an ObjectId is the default mechanism for assigning this field a value. This concept is much like a primary key in a relational database system.
A BSON document that uses the ObjectId and Timestamp data types might look something like this:
{
"_id": ObjectId("542c2b97bac0595474108b48"),
"timestamp": Timestamp(1412180887, 1)
}
When we discuss MongoDB and document-oriented databases in this text, the term JSON may be used interchangeably for BSON with the implication that this distinction is understood. You can learn more about the BSON specification at bsonspec.org.
JSON is simple, easy to read, and structured in a way that is easily understood by just about any programming language in existence. Lists (or arrays) and name-value pairs (or associative arrays) are a fundamental concept and common implementation in computer languages. The simpler a format is, the easier it is to parse, and thus more platforms will develop a way to inherently consume that data format. Such has been the case with JSON.
Additionally, the JSON specification was only changed a few times after it was first developed. Its creator, Douglas Crockford, intentionally gave no version number to the specification so that it would be set in stone and could not change over time. This may likely be the biggest factor in JSON's dominance over other data formats. Since it does not change over time, the parsers built to consume it across myriad programming languages and platforms don't have to change either. This has created an ecosystem in which JSON exists with only one version in every place, making it entirely predictable, widely understandable, and virtually unbreakable.