Book Image

Mastering Node.js

By : Sandro Pasquali
Book Image

Mastering Node.js

By: Sandro Pasquali

Overview of this book

Node.js is a modern development stack focused on providing an easy way to build scalable network software. Backed by a growing number of large companies and a rapidly increasing developer base, Node is revolutionizing the way that software is being built today. Powered by Google's V8 engine and built out of C++ modules, this is a JavaScript environment for the enterprise.Mastering Node.js will take the reader deep into this exciting development environment. Beginning with a comprehensive breakdown of its innovative non-blocking evented design, Node's structure is explained in detail, laying out how its blazingly fast I/O performance simplifies the creation of fast servers, scalable architectures, and responsive web applications.Mastering Node.js takes you through a concise yet thorough tour of Node's innovative evented non-blocking design, showing you how to build professional applications with the help of detailed examples.Learn how to integrate your applications with Facebook and Twitter, Amazon and Google, creating social apps and programs reaching thousands of collaborators on the cloud. See how the Express and Path frameworks make the creation of professional web applications painless. Set up one, two, or an entire server cluster with just a few lines of code, ready to scale as soon as you're ready to launch. Move data seamlessly between databases and file systems, between clients, and across network protocols, using a beautifully designed, consistent, and predictable set of tools.Mastering Node.js contains all of the examples and explanations you'll need to build applications in a short amount of time and at a low cost, running on a scale and speed that would have been nearly impossible just a few years ago.
Table of Contents (20 chapters)
Mastering Node.js
About the Author
About the Reviewers

Managing state

As we discussed earlier:

If changes can be introduced into a web application without requiring a complete reconstruction of state and state display then updating client information becomes cheaper. The client and server can talk more often, regularly exchanging information. Servers can recognize, remember, and respond immediately to client desires, aided by reactive interfaces gathering user actions and reflecting the impact of those actions within a UI in near real time.

A very important question every application developer must ask is this one: where should state reside?

Of course, permanent data must ultimately reside in a persistent layer such as a server-side database. As well, transient-state data (such as which navigation item is highlighted in a UI) can happily exist in the client. However, if an application displays real bank records in a data grid within a browser, how do changes made to the canonical record (the database) synchronize with changes in client model?

For example, imagine a banking application where a browser-based UI indicates to the user that she has a balance of USD 100. This UI was "drawn" based on an earlier request to a server, asking something like: What is Mary's bank balance? Clearly that number may change in the next second, or even millisecond, given the automated nature of banking. How can Mary be sure that when she pays a USD 100 bill she still has USD 100 in the bank?

One solution is to periodically expire the validity of the client state and poll a server for state changes, resynching client and server state. Additionally, client requests are revalidated on the server—Mary would be warned if she tries to spend USD 100 that she doesn't have. Client state is optimistic, and transactions are revalidated.

However, there are several problems with this model:

  • Not all state can exist on a client: Secured state data must remain on the server, which means clients can handle only pieces of state, making even the best attempt to maintain a synchronized client state imperfect by definition.

  • Revalidation is not an acceptable solution in many cases: Consider a real-time shooter. If one player alters the state of another player (let's say by killing that player), it is not acceptable to at some point in the future reanimate the killed player simply because the shooter's client had incorrect position information that renders the original kill invalid.

  • Optimism leads to false security: Meaningless is one word that can be used to described state data that may or may not be valid. For example, a stock-trading program showing the wrong price for FOO Corporation may lead a trader to short sell BAR Corporation. If the state of BAR (according to the client) matches that on a server the trade will go through, and the trader may lose money. Any single bit of information cannot itself validate all other bits of information. Indeterminacy is a feature of concurrent systems, and these systems challenge deductive state validation techniques—whether a comparison is valid cannot always be determined.

Many techniques have been used to synchronize client and server state—cookies, hidden form fields, fat URLs, and others. Path takes a different view, based on the advantages that Node provides, in particular when paired with the WebSocket protocol. If we can create highly responsive servers linked with clients through efficient pipelines, where sub-second response times are expected, it is better to simply keep important state information on the server and cease any attempts to create client-side reflections on a mirror that is easily smudged.