Real-time with Nuxt and Laravel
This episode is for members only

Sign up to access "Real-time with Nuxt and Laravel" right now.

Get started
Already a member? Sign in to continue
Playing
12. Broadcasting to other clients

Episodes

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

Transcript

00:00
So what happens if we want to broadcast to all other connected clients except ourselves? This is really helpful when you are building something like say a comment system or any kind of data
00:11
that you wanna push to a stack. Let's say that this send request button posted a comment, we get that data back and locally, we're just gonna get the response back
00:20
and push it into a stack of items within an array. Now for all other clients, obviously that's not the case because they're not the ones that have sent an API request.
00:29
They'll get the broadcasted payload which will then push that to a list of messages or whatever it is that you're doing. So basically we don't wanna broadcast
00:38
some things to ourselves. We can handle that locally and then broadcast that data to everyone else. Let's take a look at how this works.
00:45
So at the moment when I hit send request on either of these, we are broadcasting this randomly generated string that we created earlier to ourselves. To go ahead and broadcast only to other people,
00:56
we just use the to others method on the result of the broadcast function. What that's gonna do is a couple of things. We'll dive into the source code and look in a second.
01:05
What this should do now is when I hit send request here, it should only broadcast to this client. Now, when I say all other connected clients, I don't mean the user who is signed in.
01:15
I just mean any other browser windows that are open that are connected to our WebSocket server. So even if we're signed in as the same account, it doesn't really matter.
01:24
So let's hit send request and you can see sure enough, it's not working. Let's figure out why this isn't working and then we'll jump over to our client
01:31
to see how we can fix this. Okay, so let's take a look at this to others method here. And you can see that the first check is if this method exists on the event.
01:40
So somewhere on this event, this don't broadcast current user method should be in there. That's actually within, if we just open up the event that we've created,
01:49
that's within the interacts with Sockets trait. So as long as you've got the interacts with Sockets trait within your event, you will be allowed to exclude yourself
01:59
and only broadcast to others. So let's open this up and just take a look. So you can see we've got that don't broadcast current user method in here,
02:07
which is setting a property called Socket to the result of broadcast and Socket. Now we had a look at the Socket ID earlier when we were setting up Plurifle Echo
02:17
and this here will return the Socket ID for us. And then when this event gets sent, it will not broadcast to the result of what we get back from this method.
02:30
So that's how it works. But how does this get picked up? Well, it comes from a header. So what we need to do is create an interceptor
02:38
over in our client to always send across the Socket ID of the user with any API request we make to our backend. So let's take a look over in the browser.
02:48
First of all, just pull up this and let's go ahead and make this a little bit bigger, head over to our network tab and we'll filter by Fetch XHR.
02:56
Let's go ahead and hit Send Request and just inspect what we have here. So we don't have a lot of room. Let's just go ahead and go to our header section.
03:04
Okay, so our headers, if we look at our request headers, we've got the cookie stuff that we would usually see, the cross-site request forgery token, which is added by the auth package that we're using,
03:16
but there's no Socket ID in there. So let's go ahead and add that in now. So to do this, we need to create out an interceptor. Now the interceptors can be defined.
03:26
If we head over to NUX config TS, they would usually be able to be defined under our sanctum config for our requests, but this NUX config doesn't support
03:35
complex TypeScript types. So we need to define out another config and that's just going to be our app config. So let's go ahead and create out
03:43
a TypeScript file in the root and this is app.config.ts. So this is our app.config.typescript file, very similar to our NUX config,
03:53
but just allows for these complex TypeScript types. So we're just going to do pretty much exactly the same thing as we've done in our NUX config. In fact, I'm just going to copy it over,
04:03
paste it over here just to save time. So we still export our NUX config. We can just get rid of pretty much everything in here, except for our sanctum config,
04:12
and then we can define our interceptors directly in here. So the first thing we want to do is just change this over to define app.config. It's completely different
04:20
and we're going to pull in our interceptors. Now, interceptors allow us to intercept any requests. So a request, a response, anything like that, and do something with the data.
04:32
So essentially what we want to do is before a request is made, or as a request is being made, we want to update this to push a XSocketID header.
04:42
So let's just define that out so we can see what that looks like with the socket ID from Echo. So let's say on request,
04:49
so on a request to any of our endpoints, we want to go ahead and create out a function just in here, and let's go ahead and define this out. Into here, we will get the app instance,
05:01
and that's just a NUX app instance, which we don't need to do anything with, and we get the context in here, which is the fetch context.
05:09
So let's go ahead and just pull that in. So let's pull this in from OFetch, which is what NUX uses behind the scenes when you use the fetch method,
05:19
and in here, now we can do something. Just for now, just to make sure that this is working, let's just console log out on request just to make sure this works,
05:27
and let's head over to the browser and see what happens. So let's go ahead and hit send request, and yeah, that didn't work. Let's just take a look at what we've got here,
05:36
and yeah, import type this needs to be, so my editor didn't pull that in properly. Let's go over and try that again, and we may just need to go ahead
05:44
and restart npm run dev for this to work. Let's head back over, and yeah, there we go. So we've got on request. So now that we are hooked into this,
05:53
what we can do is only when we're on the client, this is really important. We don't need to set this header for server-side rendering. We'll go ahead and attach a header,
06:03
but first of all, how do we get the socket ID? Well, we know that the echo instance is bound to the window object, so we can go ahead and access that.
06:12
So it looks like this, window, echo, and really easily just socket ID. Let's not dump this out now because in a server-side rendered context,
06:20
this is not going to work because it doesn't have access to the window object. So let's wrap this in an if statement just to make sure that we are on the client,
06:27
and to do this, we use import meta client. Let's go ahead and console log this value out and just make sure that we can see the socket ID that we're connected to, and there we go.
06:36
There it is. So this will happen for all of the clients that you have open, and each of them's socket IDs will be unique.
06:43
Now that we've got this, we can go ahead and set the header that Laravel expects to be able to access the socket when we look to that over in our
06:51
interacts with sockets just here. So that socket ID will come through here, be set to that property, and then be excluded. So to do this, we just want to take our context,
07:01
we want to take our options that we are using to send this request down, and we access our headers. So you could either merge these in
07:09
if you had multiple, but in our case, we could just bind on the X socket ID, and then set that, of course, to the socket that we have here through Laravel Echo.
07:19
So let's go ahead and just paste that in, and there we go. That's going to go ahead and set that in there for us. Now we do see a TypeScript error here
07:26
because we don't have socket ID defined within the type for the headers, but we're just going to kind of ignore that for now. Okay, let's go over and just try this out.
07:34
So remember before when we used two others, this didn't quite work, of course, because we didn't have that value in. Let's give both of these a refresh,
07:42
and let's hit Send Request, and there we go. You can see that it was not sent here, but it was picked up over here, and the same is the reverse as well.
07:51
So we're just now broadcasting to all other connected client except ourselves. It's a really important thing to include because two others can be really helpful.
08:00
Like I said, when you're building something where you want to broadcast data to other people, but you want to handle the local data that comes back from your API response yourself.

Episode summary

In this episode, we're tackling a really common feature in real-time apps—broadcasting messages to everyone except yourself! Think of scenarios like live comments or notifications; when a user posts something, you want other connected users to see it in real-time, but you don’t want to show the data back to the same person, since they already have it locally.

We start by looking into why broadcasting to "others" is useful, and you're shown how the broadcast system currently sends things to all clients, including yourself. Then we introduce the toOthers method, so broadcasts only reach other connected browser windows (even if they're logged in as the same user, but in different browsers or tabs).

As we try this out, we realize it doesn’t work right away. The culprit? We need to send the socket ID with our API request, so the backend knows who to exclude from the broadcast. To handle this, we set up a request interceptor in our Nuxt app, adding the X-Socket-ID header with every outgoing request (but only on the client side, to avoid SSR issues). You'll see exactly how to hook into Nuxt’s app config, check for the client, grab the Echo instance’s socket ID, and append that to your request headers.

After wiring it all up, we test everything again and see it working—now, updates only appear on the other client windows, as intended. This is a key technique for keeping real-time UIs snappy and for avoiding users seeing duplicate updates!

So by the end of this episode, you'll know not only why you need to broadcast to others, but exactly how to set up your client and server to make it happen.

Episode discussion

No comments, yet. Be the first!