With Ozzu 2.0 I opted to go a route that uses a newer technology called web sockets which not only provides immediate real time feedback when the event occurs, but it is also more efficient. So in the same above scenario if an event just occurred, then that user (or multiple users) would immediately receive that event. I am using this for notifications and to allow members to see people post and other events in real time. So as another example, if you are on this thread right now and I hit submit on this post I just wrote, you would see it immediately flash in without refreshing your page! For web sockets I am using Socket.io on the client side with JavaScript, and Laravel Echo Server on the back-end which is a NodeJS server. My application will send an event to the NodeJS server which then broadcasts via web sockets to every listener.
With Web Sockets, there are a few more pieces you will have to consider, and one of those is having a web socket server setup that will listen to a port. Typically this will be a port other than 80
or 443
if you are using the same IP address as you will likely have your other HTTP server listening there such as Apache, Nginx, Litespeed, or Microsoft IIS.
If you are on a shared host that will also mean that you may need to contact them before attempting this as there will be a few requirements you will need to sort out:
- Are you allowed to have a web socket server/daemon running?
- Firewall? Will you be able to open a port for the web socket server?
- SSL Certificate - I automate this with LetsEncrypt, but that is its own challenge to setup.
- The WebSocket server requirements itself
If you follow the instructions on the socket.io
start page you will be installing many of the requirements very easily via NPM
, which is the Node.js package manager. Your host may or may not have Node.js
available to you.
Keep in mind that if you are unable to do this via Node.js
, there are all sorts of options out there. You could use a PHP
only solution for example such as Ratchet. If you look around I am sure you will find all sorts of different types of web socket servers. Still, for whatever solution you find it will be a daemon that is constantly running on your server, listening to a specific port (typically you can configure this), so you may still need to contact your web host.
Just remember there are at least three major pieces to using web sockets, and right now we are only talking about the first which is having a web socket server setup. You will also need to have the client-side JavaScript listeners setup that waits for events from the web socket server and then responds accordingly (like showing an alert to your user), and then likely logic in place with your main application that will communicate with the web socket server such as when you need to broadcast an event.
Overall there are many paths you can go but could be a worthy investment depending on your situation. If your time/resources are limited, HTTP Polling is still a good solution too.