I am experimenting real time app using Laravel and socket.io. I make a seperate node and redis server. Now I see several tutorials introducing redis to subscribe to channels. But I try without redis and socket.io is able to connect and emit etc.
The question is, what is redis used for and are there any specific scenarios that redis is able to handle that socket.io can't?
Thank you.
Socket IO helps in communicating between two different browser tabs, and that do not have anything to do with Laravel application only using socket.js file. So when you want to communicate between Laravel application and browser like chat or real time notifications about the events that happen in laravel application, then Redis will help you.
Laravel application send the data to Redis and Redis pass data to socket IO, then socket IO sends data to browser.
This is similar to AJAX, but in ajax the client ask for data and server/ laravel application responds to the AJAX request.
In our case the server it self can send updated data, as the change happens with out browser requesting, so this is helpful because the browser does not when the data is updated on the server side.
When I started learning socket IO and Redis I struggled a lot to find and understand this, hope this helps you.
Related
I’m bulilding a web app that requires communication between clients. For this I’m using socket.io. Some data however has to be updated regularly in the database.
Some of them not that often (preferences, on button click) others in every second for example a timer value. This can not be calculated because the timer can be paused.
Right now whenever a client emits an event, it also makes a request to the backend to updated the database. I was wondering if it would be a good idea to have the socket.io server update the database so the clients would only have to take care of the socket communication? It seems to me that having the browser do a request to the backend is a bit resource heavy and takes out a bit from the advantages of the socket based communication
Edit: the back end of the app and the socket server are two different servers but physically they are on the same machine so their communication could be faster
the main point of using socket.io is that it allows you to push data to clients and clients do not need to check your server constantly to get the last changes, and providing a low-overhead communication channel between the server and the client.
you can call an API and also emit data and many other things on user click in your application.
it is a good idea to have the socket.io server update the database and you can also authorize each socket, save client sockets information and ...
I have one api for stock trade.
this is the url for websocket communication with api server.
https://kite.trade/docs/connect/v3/websocket/
I've read about websocket for laravel, but almost are the content about sending socket request from client to server.
If then, in my case, I have to turn on browser all day long to get live market quote.
I want to make it possible to get live market data without turn on browser.
Till my understanding is, in node.js, using socket.io client, it is possible to send websocket request from server to socket server.
But in laravel, I could not find way.
If anyone has experience, please help me.
Thanks.
I am working on a project which is basically a Customer Feedback Analysis Dashboard. There are few graphs on the dashboard and data for each graph is fetched from the server through API requests.
Right now the dashboard is updated every time the page is refreshed. I want it to be updated immediately when there is a new feedback in the system. I am confused, whether I use websockets to send data for each graph or just a flag and use that flag to fetch data through API requests.
Like, facebook/twitter does. They tell you about new posts/tweets and when you click that button your feed/wall gets updated.
If you want to "push" data from server to client and you want that data to show up in a timely fashion (e.g. within 10-20 seconds of when it was available on the server), then you will want to implement some sort of "push" solution where the server can efficiently push data to the client whenever there is new data to send.
There are several possible approaches:
webSockets
socket.io
Server-sent events
Mobile platform-specific push (Android and iOS)
For a general purpose solution that works within a browser, you will want to use one of the first three. socket.io is built on top of webSockets (it just adds more features) so architecturally, they are similar.
Server-sent events are fairly new (modern browsers only) and are only for one way communication (from server to client). webSockets can be used for communication either way.
I'd personally recommend socket.io because of the features it offers (such as automatic client reconnection) and a simplified messaging layer. You can see the feature difference between socket.io and webSockets here. With socket.io, the client makes a connection to the server when the web page is loaded and that connection is persistent. After the connection is established, then either client or server can send messages to the other at any time in a very efficient manner.
Other useful references:
Push notification | is websocket mandatory?
websocket vs rest API for real time data?
Why to use websocket and what is the advantage of using it?
What are the pitfalls of using Websockets in place of RESTful HTTP?
Ajax vs Socket.io
I am a bit confused about how one uses websockets. I have already set up a websocket server and are able to receive from server and send to server.
My question is. When using websockets, are you supposed to drop the ajax part completely? Or are you supposed to use websockets alongside ajax?
Example:
I want to use websockets on a chat service on a website where users can log in. When logging in, I use ajax. When on the message page I use websockets to receive future messages, and send future messages. But when navigating to the messages page, I use ajax to get the messages from database.
Is this the correct way of using websockets? Or should I do everything in websockets since 1 user 1 active connection is more efficient? Or should 1 user have 1 websocket connection, but still keep sending ajax requests to the server when navigating to some pages without reloading the site, using ajax?
What is the best practice when creating a large application where users can log in, navigate to pages to load stuff async, but still wanting that bidirectional real time benefits of websockets on stuff like messaging services and notification services on that same website?
There is no reason you cannot use both. I think the solution depends on what server side resources you are using. I may need access to a server through websockets to get updates to a chat dialogue. I may use a completely different system to get user statistics or provide authentication.
I don't think there is a specific answer to your question as it varies depending on the application in question.
I'm giving socket.io a whirl and I'm curious as to what I should and shouldn't be doing with websockets.
For example is there a way to authenticate a websocket (include id in every message perhaps?)? Let's say I'm creating a 'google docs' like app in which people can create new documents. Should I be using AJAX to create new documents instead of websockets? That way I can use the standard HTTP transport layer to do all of the user authorization (checking session, etc) and then simply ping back the page with a websocket event. Curious as to how people handle situations like this.
I would recommend using AJAX wherever you do not absolutely need web sockets. Web sockets end up creating more load on the server side (socket.io will take care of fallbacks in case web sockets & flash sockets are not available). In short, use web sockets where you need to maintain that state/connection to the client.
If you wish to use web sockets, using cookies with socket.io would be one approach that would allow you to keep track of your sessions. If not using socket.io right away, you can send req.sessionID (key) to the client, store the session information in Redis/Mongo etc. When the socket.io connection is attempted, read the cookie value & send it to the server - where you can get the session store information. There may be issues if you use flash sockets as one of the fallbacks.
Hope this helps.