Okay, I just want to start by saying sockets are awesome! I love sockets. We used sockets for a single day at the Dojo before moving on to MongoDB, but man did they leave a good impression. It’s about to be project week now and I am excited to say that I will finally be using sockets again! But before we get to sockets, I should probably summarize express real quick.
Express is a handy overlay for Node to expedite all of the tedious parts of setting up a server. Want to serve a bunch of static files? Just tell express where your static folder is and you’re good to go. You can even add more than one static folder! Want to parse some post data? Just hook up your handy-dandy body parser! Want to define some routes? Well, you get the idea. It’s not super exciting, but Express does everything Node does with less code. Hence the name, Express, lol.
Well that was nice and short, wasn’t it? That’s the beauty of Express, it’s nice and simple. I’ll put some real code examples in the post I’m planning to do on sockets later because Express and sockets work nicely together and that’s how I originally learned about them. This post is only going to contain a high level overview of what sockets are and why they’re awesome.
So, in order to illustrate the awesomeness of sockets, let’s think of an example. Let’s say we want to make a group chat app. We already know how to use jQuery to make our clicks on the “send” button activate an AJAX post request. We also know how to make our sent message pop up on the screen without refreshing. But what about when someone else in our chat room sends a message? How do we get their messages to automatically pop up on our screen?
We know how to use jQuery, but jQuery only works by binding handlers to specific events on the client. We can make a “refresh” button that, when clicked, makes an AJAX call to the server to request all the new messages, but that’s super lame! We would have to be constantly clicking the button to check if there are any new messages! We all know how a good chat app is supposed to work, and a refresh button is definitely not going to cut it.
The problem here is that our client doesn’t know anything about what’s in the database until we ask the server directly with some request that we initiate. The server won’t talk to the client unless the client sends a request first. So, if we just sit there and stare at our chat room without pressing any buttons, nothing will change…
What we want is for the server to tell the client whenever there is a new message, right? But in order for that to happen, we need to turn our request/response cycle into a two way street! This is where sockets come in!
Sockets are almost like a replacement of the standard old request/response cycle. Instead of having a server that is only listening for single requests from clients and then terminating each connection after sending the proper response, we have a server that initiates a connection to each client and then stays connected as long as the client is active! This lets us fix the problem we had earlier with the client being the only one able to initiate a connection. If the client and the server stay connected, they can talk to each other as much as they want! Plus, since the server can have multiple connections to multiple clients, this setup is perfect for our chat app! Let’s take a look at some new vocab for socket functionality.
- Emit – This is kinda like the new word for “request/response,” though since now it can go both ways, it’s a bit different. A client can emit to the server, and the server can emit to a client. We can pass data by emitting either way.
- Broadcast – This is when a server emits to all the connected clients except for the one that triggered the server to do so. Imagine when you enter the chat room and everyone except for you sees the little message saying “Some dude entered the chat room!”
- Full Broadcast – When the server emits to ALL clients currently connected. For example, when anyone posts a message, everyone should see it pop up on their screen, including the person that sent the message.
So, using these three data transfer methods available to us, we can imagine how our chat room app should function.
- Whenever a client connects to our server, it will emit an event saying that a new socket connection is initialized. The server will receive this event and broadcast to all other connections the “new user has appeared” event.
- Whenever a message is posted, the client posting the message will emit a “new message” event to the server, which store the message in the database and full broadcast an event containing the updated message list to all connected clients. Thanks to this, even if multiple people send messages at the same time, everyone will aways stay up to date with the current messages.
- When a client disconnects, it will emit a “disconnection” event to the server which will then broadcast a notification that whoever has left the chat room.
And there we go, we now have a nice little chat room app concept using sockets! I’m trying to blast through these catchup blog posts as fast as I can for now so I apologize for not going into detail with code examples, but I’ll get back to sockets later. I should be able to give some real examples from the project I’m about to start tomorrow as well!