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.
