HTML and CSS Reference
In-Depth Information
So good documentation with lots of code examples can make the difference between deciding to use a service
or not. Pusher's documentation
3
is a combination of user guide and reference, focusing on both exploring what is
possible and letting you quickly find a way of achieving something.
Pusher Terminology
Before we get started with Pusher you should become familiar with some of the terminology.
A
connection
represents a persistent connection between a client, in our case a web browser, and the Pusher
service. Messages are received via Pusher over this connection and we can also send messages to other users,
via Pusher, over this connection.
Pusher uses the
publish-subscribe messaging pattern
4
so uses the concept of a
channel
to identify something that
the client application is interested in (e.g., “sports-news” or “apress-tweets”). A channel is represented simply by a
name, and you register interest in a channel by
subscribing
to it.
Some have referred to the realtime web as the “evented web.” This is because realtime web technologies are
frequently used to communicate that some sort of event has occurred, and to deliver the data associated with that
event to users or systems that are interested in knowing that it has occurred. For example, when somebody tweets,
the system might inform all their followers about that tweet event and deliver the tweet data (twitter user, text, time of
tweet, was it in reply to another tweet etc.) to them.
So, it may come as no surprise that Pusher also uses the concept of
events
. Events are used in conjunction with
channels; when you subscribe to a channel you can then bind to events on that channel. For example, you could
subscribe to the “apress-tweets” channel and bind to “new_tweet”, “tweet_deleted”, “tweet_favorited”, and “retweeted”
events. Events tie in really nicely with create, update, and destroy parts of CRUD (create, read, update, destroy)
functionality; as well as user interface changes that reflect the result of an event.
In order to receive data, it has to be
published
. Data is published on a channel and associated with an event. To
maintain the concept of the evented web, the act of publishing data on a channel is called
triggering
an event. As such,
trigger
and
publish
may be used interchangeably.
You'll see all these concepts in use as we develop our application, and this will demonstrate how you can easily
use the same concepts in new or existing applications.
Getting Started with Pusher
The first thing you'll need to do before we start building an example application is sign up for a Pusher sandbox
account. This is a free account that limits the number of simultaneous connections you can have open from your
clients and the number of messsages you can send per day. This free account will be more than enough for all the
applications presented in this topic.
Once you've signed up, you'll be taken to your account home page, which has all the information you'll need to
do a quick proof-of-concept for your account (see Figure
3-1
.)
Search WWH ::
Custom Search