Check out a free preview of the full Complete Intro to Real-Time course

The "Sending & Receiving Data" Lesson is part of the full, Complete Intro to Real-Time course featured in this preview video. Here's what you'd learn in this lesson:

Brian codes the remaining elements of the Socket.IO exercise. Custom events are create for sending and receiving messages. The client and server applications listen for the custom events which are sent by Socket.IO using the emit method.

Preview
Close

Transcript from the "Sending & Receiving Data" Lesson

[00:00:00]
>> So let's get the initial get going. So in server.j s, so on a connection, We're gonna say right here, socket.emit, which is how you like admit or you write out events to clients. We're gonna make an event and we're just gonna call it a message called get.

[00:00:25]
So this is arbitrarily named, we can name it whatever we want. It's just like the name of an event. And then your clients can subscribe this some events, right? Maybe there's a new user connect or there's a, I don't know, whatever kind of events you can think of.

[00:00:42]
You can subscribe to some of them, you can not subscribe to some of them, all that kinda stuff. So we're gonna emit to that client this message get event, and we're gonna say all chat, sorry. Not that rather, I'm mixing up my thing here. Rather you're gonna admit the payload with it, which is gonna be message, get messages, like that.

[00:01:15]
So now we're going to send to the client your messages. Smaller again. And then we're gonna come down here to socket.io chat. And we're just gonna say, just like we say on connecting on disconnect, we're just gonna say socket.on, whatever the name of our event was. Was which was messaged get run this code.

[00:01:43]
So this is what I'm trying to illustrate too now, is that socket.io is a messaging busing system, right? Almost like, something like simple queue service can be for Amazon AWS, just like Kafka and things like that. So you can kind of do with these kind of pub sub sort of things.

[00:02:06]
Not totally the same, there's wild differences there, but just the general concept there of pub sub is available too. So we're gonna say All Chat Equals data.message. And then we're gonna call render. So anytime you get new messages, just render that business. Basically always you're saying there, Okay, There you go.

[00:02:35]
So now you can see the messages are coming back from the server and is rendering just fine for the user. Okay, let's go right to the server now. So here in socket IO chat, we're gonna write our post new message here. So we're gonna say same const data equals user Text and we're just going to say socket dot emit.

[00:03:07]
Message post, Data. So now we're just sending that same data back to the server using the same sort of methodology here. We just gotta wait for that on the server. So here socket.on message post. Grab the data run this function, and we're gonna say message push. User, data.user.

[00:03:53]
Text, data.text, and time, date.now. So this is the part that hopefully will kind of blow you away of just how easy this part is. Now we want to rebroadcast this out to all users connected to our socket.io instance, right? You're just going to say IO instead of socket, right?

[00:04:21]
Which is just the individual socket that you're working on, right, iO represents the entire server. So we can just say IO.emit. Message get, Message colon, and get messages And that's it. To now to broadcast and the entire server, it's just send it out, send it to everybody. I think that's pretty compelling.

[00:04:59]
All right, so now we have Brian here, and we can say, And Open another instance here. Right and it's just happening on both sides here. This is the killer. If you look at line 38 here, it's like, that's the part, that's the killer part of socket.io for me.

[00:05:38]
Then you want to use socket.io because those kind of features are built into socket.io. And you might be thinking like, well, that's gonna send it to everybody, right? What if I just want to send it to some users, right? That's what the concept of rooms are for, right?

[00:05:51]
We can actually put groups of users into like a room of users. And then you can just broadcast on the room instead of on the entire server, right? Which is basically like a pool of users that you can send things out to, and that's what these messages are for.

[00:06:05]
You might wonder, why did use a colon there? It's like namespacing kind of for messages. It's really common. You'll see it like in Redis and socket.io in other places like that. Where it's the message namespace, you can see I've messaged post, a message get, I could have user update, and user change, and things like that.

[00:06:23]
And you could actually have different namespaces of commands, right? And all sorts of fun functionality that comes along with that. But hopefully, you've watched the entire course of this portlet, where we've kind of built up this idea of, I want to send a message from a user to a server.

[00:06:39]
And then broadcast out to a group of users. He was kind of building up to basically this one line of, look how easy this is, how easy it can be and how impressive some of the software really is. And this is really it, like I said, there are more features to socket.io.io and WebSockets, but this is the groundwork for all.

[00:07:02]
It's all kind of just permutations of this right of allowing users to listen to some events and not to others, basically. And the good news is, that's it that like this is really it for socket.io. There's not any more code to be written here. What took us lines, and lines, and lines of code to write for WebSockets and HTTP to push and all that kind of stuff, is accomplished on what?

[00:07:29]
24 to 40, pretty cool stuff. So, this is it for the the coding of the of the course. Just to kind of give you some general high level ideas of if you wanted to like dig more into this and kind of figure out some more stuff for this.

[00:07:55]
You could convert this page here to a react app or to a svelte or Angular Ember app or something like that. Or view and see how your favorite framework can interact with WebSockets because they all kind of have their own ways of doing it, right? With react yet be careful to not not dispose of the connections, right?

[00:08:16]
That's a really easy thing to do. With Vue, there's like reactivity there's you can actually build that into like the reactive parts of the framework, which is kind of fun thing to do. You can plug sockets into RX js and you can get like reactive sockets, which is pretty compelling.

[00:08:32]
All sorts of fun stuff there. You can get into like private messaging between users. So you could have two users and you could have the ability to send private messages to each other and how you would try and secure that. You can do authentication and authorization. There's nothing special here for auth for WebSockets.

[00:08:48]
It just works the same way as HTTP two or HTTP in general. What's just gonna be like a cookie or a session or something like that. You can add rooms, we talked about that. You can have a super user or an admin that can see all the various different room activity.

[00:09:05]
And then another good one would be to connect this to Reds or two MongoDB, or something like that, and actually perpetuate this beyond into a database. Those are all be really good projects for this. The complete project here is down here at web socket slash socket IO. That's all here.

[00:09:31]
>> You mentioned at some point about a cue type of service. That socket IO is kind of implementing under the hood. Does it have anything built in for prevention of data loss?
>> Good question. It does not have any sort of data loss functionality built into it as far as I know, right?

[00:09:55]
With something like SQL, it'll hold on to events until someone slips Ascribes to listen to them. That's not necessarily built into socket.io, but I would imagine someone has built it. There's probably like libraries on top of it. But I mean, at the end of the day, you could just put it into like your own Reddis queue basically, and wait for a user to read.

[00:10:14]
And then you can just drain it whenever the user connects to it. That'd be a good way of doing it.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now