#How to emit events from client to server websockets

54 messages · Page 1 of 1 (latest)

paper hare
#

I' ve built a Laravel API which broadcasts events through Pusher, and listen for these events in the Client using Laravel Echo. However, now I need to emit events from the client to the API, how to handle that with Laravel? Should I use a socket.io server with node and then modify the database throught the node server?

copper osprey
#

Or send data to the server via AJAX.

desert wharf
#

Client to client (whispers) are fine, but bidirectional back to the backend server...nono.

#

Ah yea, as martin said, just submit good ole http request in the background to your backend.

paper hare
#

Is there any way to know when a client connects and disconnects?

desert wharf
#

What are you trying to do?

#

On the client side yes, easy hook into connect/disconnect events.

paper hare
#

I have several raspberries with a nodejs app installed on them, where this node app connects to the Laravel API through Laravel Echo. Until now, everything is working fine, however, now I wish to store in the database if the Raspberry is connected/online

#

When the client connects, I wish to set the column to true, and when it disconnects, to false

#

The node app is a offline-first app for showing posts with images/videos

desert wharf
#

Few ways to look at that, but also issues. You could make an http request from the pies to backend upon connect/disconnect. However, if a pie outright died, you'd need other automated ways of knowing it went offline.

#

Some websocket implementations have an http interface to query channels, but I would not do that IMO.

paper hare
#

But what is the pi loses internet connection, I cant make a HTTP request

desert wharf
#

You could have a PIE post when connected, and some ping POST on an interval to keep updating a timestamp or something in DB.

#

Then a scheduled task to see if something is marked online but last timestamp is older than a minute or something

copper osprey
paper hare
#

yes, thats what i was thinking

desert wharf
#

I do that with my video calls.

#

Everyone on websockets but I keep participants in a table and cache status as "in call" from heartbeats every 15-30 seconds

#

Every minute, if there are participants in an active call but not in active cache, I mark as left

paper hare
paper hare
desert wharf
#

same idea as ping

#

just some communication on an interval to the server

#

to keep the "wire open" so to speak

#

just like your very websocket connection is always sending ping/pong back and forth

paper hare
#

Thank you. But what if i REALLY need someway to the client to send messages to the backend, I'll need to use other technology? Not Laravel?

desert wharf
#

Why can't you just use http calls?

paper hare
desert wharf
#

I promise your server is not going to break a sweat from a few pies pinging it every 15-30 seconds

#

You should see internal readiness checks with kubernetes...http calls many times per second.

paper hare
# desert wharf Why can't you just use http calls?

Lets say for example want to know which post the current raspberry is playing. Right now, the node js app is the one how calculates which post must be showing, and when to change it. What if I want to send a request to the laravel api when the post changes, so the frontend is in sync with what is being shown in the raspberry. Websocket connections are much faster, arent they?

#

If i need it to be as close to really as possible

#

If I use HTTP, then a post could be showing for 1s, until the request reaches the backend, the post could already changed

copper osprey
desert wharf
#

You can do two things at once? Why can't your PIE both WHISPER to the other clients on sockets that X is happening, while also POSTING HTTP to the backend to update official record.

#

(if using presence channels)

paper hare
#

Didn't think of that

#

Another question, why you cant send client events to Laravel? Whats the reason

desert wharf
#

Because websockets are not meant to interact backwards to the server, in this case (and most implementations).

#

Laravel has the secret key on the backend to push out events to the websockets, and your clients get be authorized to gain access to channels, which lets them receive events, but also if presence, emit events back up the wire to others on the same channel, because it goes to the socket server and right back out, but never back to the http server.

#

You'd need to design a good few things yourself if you planned to trust input coming backwards from sockets and how to post that back into your laravel app / DB

#

Socket server implementations by default do not usually offer such things, not designed for that IMO.

#

Now sure, I use a tool that does use sockets to edit the server itself, but it is a media server and http/websockets are both transports to the same underlying system. While laravel and a socket server are not inherently acting as the same transport.

paper hare
#

This was pretty clarifying, thank you so much. I'll need to study a lot more to understand this better, however you helped a lot.

copper osprey
#

But obviously there are then security considerations around that.

paper hare
#

Thanks, I'll read that.

#

For now, I'll stick with the ping requests and presence channels. Thank you both

desert wharf
#

So just to expand on how my "pings" work. I use cache in combination with DB columns

#

So I'd imagine for you, say you have pies table. Each Pie has is_online and last_active_at. When the pie comes online and connects to socket, setInterval(ping) every 15 seconds or w.e is reasonable to you. When your laravel app gets a ping, check DB for that Pie, and set online to true, and active to now(), but also set a short cache entry, like Cache::put("pie:$pieId", true, 30);. When pie goes offline, you could add another POST to laravel to immediately mark it as offline and remove pie:$pieId from cache, and whisper offline over presence, or/in-addition to relying on the task scheduler to schedule a check each minute, where you query DB for all Pies where is_online is true, and check if the pie:$pieId is in the cache, and if not, update that record as offline.

#

https://github.com/RTippin/messenger/blob/1.x/src/Http/Controllers/Actions/CallHeartbeat.php#L29
https://github.com/RTippin/messenger/blob/92cca2804e74b79319be6177083c728ca0244038/src/Models/CallParticipant.php#L82-L103
https://github.com/RTippin/messenger/blob/1.x/src/Commands/CallsActivityCheckCommand.php
https://github.com/RTippin/messenger/blob/1.x/src/Actions/Calls/CallActivityChecker.php
https://github.com/RTippin/messenger-ui/blob/master/resources/js/managers/CallManager.js#L174 /old/shit JS but still a reference for ya