Database Reference
In-Depth Information
Tip
Because WebSockets and SSE use different endpoints and different
protocols, a server can easily support both of them as transport
mechanisms for streaming events. This is especially useful when you're
trying to support a large number of devices or even native
implementations (in the case of mobile devices).
NOTE
A third technology for streaming communication between the server
and the browser is the WebRTC standard. Originally developed for
peer-to-peer audio/visual communication, this standard also has the
ability to transmit arbitrary data across the wire. Support at the
moment is limited only to newer desktop versions of Firefox and
Chrome. The hope is that this will change in the not too distant future,
providing a rich new streaming data interface.
A Redis-Based Dashboard
While the in-memory counter state with a REST-style interface is useful for
development, the previous chapters have covered the data pipeline for a real
streaming web application. In this case, stream processing is handled by
either Storm orSamza, and updates are sent tosome sortofpersistent store.
Aggregation and maintenance of counters is covered in more detail in
Chapter 8, “Exact Aggregation and Delivery,” but you can easily adapt the
simple counter dashboard frombeforetoapersistent store.Thiscanthenbe
driven from a stream-processing environment.
This example uses Redis because it is a relatively simple key-value store
that also has a pubsub facility that is used to drive the updates. A persistent
storewithoutthiswouldrequire anadditional messaging facility todrivethe
dashboard servers (or use polling on the server side to drive updates).
In the example dashboard, the server keeps track of a single Redis hash that
can be updated by external interfaces as well as by the dashboard interface.
