This content is incomplete and may be inaccurate, feel free to look around & please check back later for updates.
When thinking about sockets you would almost instantly go to languages such as NodeJS (JavaScript, Typescript), or Python, or even Go. With Javascript being the language of the browser and most likely listening to the socket itself, it makes sense to have it be at both ends. Or if you’re developing IoT devices you might gravitate towards Python to keep the language the same. The architecture also plays a role where microservers or serverless makes sense – and the big cloud providers (eg. Amazon’s Lambda service) tend to stick to those languages listed earlier. But what if your logic is built on Laravel (PHP) or another primarily backend language?
Why use websockets?
I have utilised websockets previously in my remote controlled lego project allowing a mobile app to control a number of motors, servos, and lights in real time. This used a trick so the socket was actually controlled by PHP itself – not the best scalable approach but it was a proof of concept and it shows a socket isn’t defined by the language. Why do people tend to use websockets for more real-time projects though, why not just use basic web requests a few times a second? This is where it’s important to understand what a websocket is, how it works, and what it brings.
A standard web request works something like this…
- The client (typically a web browser) opens a connection to a server
- The client then requests a document from that server
- The server then executes what is needed to retrieve or generate that document
- The server returns the results
- The client reads & stores those results
- The server closes the connection
This works well – it’s been battle tested trillions of times for decades, it’s secure, it’s standardised. The downside is there’s a few overheads there – it has to open the connection every time which contains many back and forth steps with security negotiations, and the document request is bulky. There are some workarounds for these like keepalive, but it’s not as efficient as it could be. And if we want to send data back it’s an entirely new connection.
A websockets request basically removes all the reconnecting and request structure from the process and looks like this…
- The client (web browser, device, anything) opens a connection to a server
- The server then upgrades that connection to a socket
At this point the socket is kept open with the server and client keeping in touch automatically waiting for the other to speak.
- The client or server sends a packet of data on the socket
- The server or client reads that packet of data and enacts on it.
All the overheads of reconnecting, requests, delays with polling are gone – it’s real-time back and forth communication. The downside however is we have lost all that framework of requesting documents and clearing the data on each request, so different problems are now introduced.
So you wouldn’t use websockets for loading websites as that technology isn’t required. However for specific areas where real-time communications are required (such as chat applications or notifications) it works well – but it needs something to help bring the scaffolding back so we don’t end up building our own protocols. Which brings us back to Laravel.
How Laravel works with websockets
Because Laravel is built with PHP it doesn’t directly create websockets – it’s not it’s own webserver so it can’t upgrade the connection. The workaround is to push data to a 3rd party service which handles the sockets and all the traffic instead. For our example we’re going to use the ‘Pusher’ protocol with the free server alternative called ‘Soketi’. Soketi is a pusher compatible server built in Javascript/NodeJS, meaning it’s able to create its own server and upgrade the connection to a socket, and is extremely efficient. So for this example it’s role will look something like this:
- Laravel pushes data to the server (Soketi)
- The server (Soketi) makes that data known/available to all the clients
That’s the sockets themselves taken care of, and it’s scalable and low cost.