One Million Checkboxes with Laravel
This episode is for members only

Sign up to access "One Million Checkboxes with Laravel" right now.

Get started
Already a member? Sign in to continue
Playing
07. Bi-directional websocket communication

Episodes

0%
Your progress
  • Total: 1h 17m
  • Played: 0m
  • Remaining: 1h 17m
Join or sign in to track your progress

Transcript

00:00
If we were sending a request down to our server with an AJAX request, whenever when one of these boxes was checked, this would be incredibly easy to pick up when a specific checkbox was checked.
00:12
At the moment, though, we're doing all of the communication client to client. None of this is going through our back end, but it is, of course, going through the reverb server. So what we need to do is look at how to use bidirectional communication
00:28
with our WebSocket server, so we can pick up these client events on the back end and then do something with them. Now, you might be thinking, well, why don't we just, in that case, if we're doing some sort of check on the back end,
00:41
go ahead and just send an AJAX request down. The point is, we don't want to do that. We want the client to client communication to be as fast as possible. But in the background, and even within a Q job,
00:52
we want this to be picked up and then set inside of Redis. Because we're going to use Redis, each of these detections is going to store this data incredibly quickly. Now, the first thing we want to focus on is how we actually pick up client events on the back end.
01:09
Let's go over and do this now. So what we want to do is listen to the message received event directly from the reverb package. So whenever we get a client event and that goes through reverb, in fact, any event that goes through reverb,
01:27
this message received event will be fired off. So we can actually hook into this and listen to it. And we'll do some logging to make sure that we are capturing the right data. OK, so let's go and create out a listener in our application.
01:41
So let's create out a listener called HandleStateUpdate, of course, whatever you want to call it. And let's go over to HandleStateUpdate. And in the handle method just here, let's just log out some data.
01:57
So let's log out info and let's just say handled. And we'll make sure our Laravel log is completely clear. OK, so we want to hook up this listener to that message received event. We can always type in this in here,
02:12
or we can go over to our app service provider and manually bind this in. So let's say event from illuminate support facades, listen. And we want to listen to that message received event from reverb. And we want to handle that with our HandleStateUpdate listener.
02:36
OK, let's go ahead and restart our WebSocket server. So let's close this off and rerun it. And we should start to see this data roll in. So you can see for every one of these events now, even client side events,
02:49
when we connect to our server, this is going to be pushed into here. So every time we do anything, like check a box inside, it's going to go ahead and fire this event off. Now, we don't want to listen to any event inside of HandleStateUpdate.
03:04
We want to specifically listen for when a checkbox is checked. So we want to listen for that client state event that we get when we check a checkbox. So let's start to pull the data out of here,
03:16
and then do a comparison and check that we are watching for the right event. So first of all, the data that we get from the event message, and we can see all this in our console just over here, the messages that come through, we want to go ahead and JSON decode this.
03:33
So it will be sent and received as JSON. Then we want to grab the data from that payload that we've just used JSON decode on. Let's say payload and data.
03:43
Let's just go ahead and log out here the payload event, just so we can see these events rolling, because this is what we're going to need in that comparison. And this is going to be all the data when we know we want to react to this.
03:56
So back over to Laravelog, let's just clear this all out. We'll need to restart our reverb server once again. And if we head back over to the browser and just click these a couple of times and go back over, you can see we get push a subscribe client state.
04:10
Now, this is when a checkbox was checked. So we want to compare this to client state. So we know we are handling the right event. We don't want to handle anything else here.
04:20
We only want to know when a checkbox has changed. So let's compare the event to client state. And we'll actually say if it doesn't equal this, we'll just return. Otherwise, down here, we want to update Redis, which we're going to look at soon.
04:35
So let's go and just log out here. Update Redis so we know that that is coming through properly. Once again, let's go over to our Laravelog and clear that all out. Restart our reverb server.
04:49
And let's go over to the browser. And I'm going to check this four times. And if we head over to our log, there we go. We get four logs.
04:57
So this will contain all of the data about that state update. If we head back over to this, we could also log out the data. And let's go ahead and JSON encode this, because otherwise, we're going to be dumping out a class.
05:16
And let's go back over and rerun our reverb server, clear out our log. And let's try this out again. So I'm just going to click one of these. Remember, this is checkbox one.
05:26
If we head over there, we get ID of one, checked, true, great. So now we can take this data, and we can store it in Redis. And then obviously, when a user refreshes the entire page here, we can take that Redis data and pre-populate all of the checkboxes
05:41
that have already been checked. But that, in a nutshell, is bidirectional communication. What we're doing is we're hooking into the reverb server to pick up any client-only events to react on them events.

Episode summary

In this episode, we're diving into how to catch client-side events on the backend when using websockets—in this case, with the Reverb server. We start by comparing this approach to the more traditional AJAX way (which would be simple for tracking checkbox changes). But since we're aiming for real-time, efficient client-to-client communication, we want to avoid sending AJAX requests for everything and instead leverage websockets for speed.

You’ll see how we listen for events sent between clients that pass through the Reverb websocket server. The goal is to catch, on the server side, whenever a checkbox is checked in the UI by any client. We walk through creating a listener (HandleStateUpdate) that subscribes to the relevant event from the websocket server. We'll set up some logging, restart the server, and see the events ping back as checkboxes get checked.

To make things more selective, we parse the payload and filter down to just the events we're interested in—namely, when a checkbox state changes. Once confirmed, we can then log that info and, as a next step, get ready to persist it to Redis. This is so that checked state can be remembered and re-populated for any user!

It’s a hands-on look at how you can have the backend react in real-time to changes on the client without AJAX, all thanks to bidirectional websocket communication. By the end, you'll see how to wire everything up so your backend knows exactly when a user checks a box, and how we can store that update efficiently for later use.

Episode discussion

No comments, yet. Be the first!