connected
> hello
< hello
The connected message is displayed when WebSocket has connected to the server, and the onopen function handler has been called. The code then logs > hello to indicate it’s going to send hello over the WebSocket connection to the server using the WebSocket send function. Finally, when the server echoes back the message, the onmessage function handler is called, and < hello is logged to the console.
This demonstrates how to use the WebSocket API and gives you a glimpse of how useful it could be. But, as we covered in Chapter 1, the WebSocket API is not fully supported in all browsers just yet, and we need a fallback mechanism. As a result, implementing realtime apps can be cumbersome, tricky, and extremely time-consuming if we have to handle browser compatibility issues ourselves.
Fortunately for the rest of us, there are a number of services out there that have overcome these hurdles and created APIs that start by checking for WebSocket support; then regressively check for the next-best solution until they find one that works. The result is powerful realtime functionality without any of the headache of making it backward-compatible.
Among these companies offering realtime services, Pusher stands out for its extreme ease of implementation, free accounts for services that don’t have large user bases, great documentation, and helpful support staff.
Pusher provides a JavaScript library11 that not only handles fallbacks for older browsers but also offers
functionality such as auto-reconnection and a Publish/Subscribe12 messaging abstraction through its API, which can make it much easier to use than simply dealing with generic messages, as would be the case if we used the native WebSocket API.
Finally, because Pusher is a hosted service, it will handle maintaining the persistent connections over which data will be delivered and can deal with scaling to meet demand for us. Although this latter point might not be a big deal for our sample application, it’s a valid consideration when you are building a production application.
For those reasons, we’ll be using Pusher in this book to build our realtime.
Why Do We Need It?
Pusher will allow you to add realtime notifications and updates to the application, including the following:
• Updating all users when a new question is added: This means that when a user adds a new question, all users currently using the app in that room will receive the new question immediately.
• Updating attendees when the presenter marks a question “answered”: When the presenter answers a question, marking it “answered” will instantly update all attendees’ devices to prevent confusion.
• Updating the presenter when more than one attendee wants the same question answered:
If more than one user is interested in having a question answered, they can upvote that question. The presenter will receive a visual indication to let them know that the question is pressing.
• Updating all attendees when a room is closed: When the presenter closes the room, attendees need to be updated so they know not to ask any questions that won’t be answered.
What Role Does It Play?
Pusher will play the role of the app’s nervous system: it will be informed when changes are made and relay that information to the brains of the app so that they can process the information.
11http://pusher.com/docs/client_libraries/javascript
12http://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern
Chapter 2 ■ the tools
How Does It Work?
In the simplest terms, Pusher provides a mechanism that lets the client “listen” for changes to the app. When something happens, Pusher sends a notification to all the clients who are listening so that they can react appropriately. This is the Publish Subscribe paradigm we mentioned earlier.
Chapter 3 is dedicated to the finer details, so we will skip the exercise in this section.
OAuth
Unlike the technologies discussed so far, OAuth is a protocol, not an actual programming language. It’s a concept that was drafted in 2007 to address the issue presented by websites that provided services that overlap; think about how social networks can access your address book to look for friends or how a photo sharing site can tie into Twitter to let your followers know when you’ve posted a new photo.
The problem was this: when these services first started to work together, they required that users provided a username and password to access the service, which was potentially a huge risk. What was to stop a shady service from using that password for its own purposes, up to and including the possibility of changing your password and locking you out?
This was a big concern. OAuth devised a solution based on its study of a number of other attempts to solve the problem, using what it considered to be the best parts of each.
To paraphrase an excellent analogy from the OAuth website:13
OAuth is like giving someone the valet keys to a luxury car. A valet key will only allow the car to drive a few miles; it doesn’t allow access to the trunk; it prevents the use of any stored data in the cars onboard computers, such as address books. OAuth is similar to a valet key for your online services: you don’t provide your password, and you’re able to allow only certain privileges with the account without exposing all of your information.
For instance, Facebook uses OAuth for user authentication on third-party services. If you’re already logged in to Facebook, you’re presented with a dialog (on Facebook’s domain), telling you which permissions are required and allowing you to accept or deny the request. Privileges are compartmentalized—reading someone’s timeline is different from viewing their friends list, for example—to ensure that third-party services receive only the privileges they need to function.
This keeps users safe and reduces liability for web apps. It also provides a wonderful benefit for developers: we can allow a user to log in to our app with their Facebook, Twitter, or other credentials using a simple API.
Why Do We Need It?
We don’t need it in the app that we’re building, but it would be a neat feature so we’ve included it in Appendix A if you want to see how it could be included. In a nutshell, we would use OAuth to eliminate the need to build a user management system. This would also hugely reduce the time needed to sign up for an account without reducing the app’s access to the information it needs to function.
Let’s face it: most people have more accounts than they can remember on the Internet. The difference between someone using our app and not using our app could be something as simple as how many buttons he has to click to get started.
13 http://oauth.net/about/
OAuth provides a great way to get everything we need:
• Verify that the person is indeed real: We can reasonably assume that anyone who is signed into a valid Facebook or Twitter account is a real person.
• Collect necessary data about the user: For this app, we would really only need a name and e-mail.
• Reduce the barrier to entry: By eliminating all the usual steps of creating an account, we could get the user into our app in seconds with just two clicks.
What Role Does It Play?
OAuth would be the gatekeeper for our app. It would use third-party services to verify the authenticity of a user and gather the necessary information for the app to function.
How Does It Work?
You’ll find more details on the specifics of OAuth in Appendix A, but at its core, OAuth contacts the service through which we want to authenticate our user and sends a token identifying our app. The user is prompted to log in to the third party service if they’re not already and then allow or deny the requested privileges from our app. If the user allows our app to access the requested data, the service sends back a token we can use to retrieve the necessary data and consider a user “logged in” to our app.
Summary
At this point, we have successfully defined a rough list of functionality and requirements for our app. We also used that information to flesh out a list of tools we will use to bring the app to life.
In the next chapter, you’ll get familiar with Pusher and its underlying technologies, and you’ll build your first realtime application.
Chapter 3
Pusher
Now that we’ve laid some foundation for the app and reviewed some of the programming languages we’ll be using to build it, you can start getting familiar with the new technologies that will come into play.
First, let’s get acquainted with Pusher, which will be responsible for the realtime interaction on our site. In this chapter, we’ll explore the origins of Pusher, the underlying technology, some of the tools they provide to help development, and get our hands dirty by building a simple realtime activity tracking app.