Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
The way I did it for my kahoot clone is that a user submits an answer through the socket, and then the sockets broadcasts a message to all to update their state.
The quiz master stars a game by calling a route and then connects oj a different route with the websocket
No http communication occurs except for an authentication step.
Following some new nextjs tutorial to learn how to efficiently build a web chat app, the guy built it very solid, but is it efficient?
Im having mixed feelings about this approach. The way he did it is, for example when you click on a user (imagine it as a list of users from your contacts), it actually calls a route, which stores that in database, and once its done Then the route triggers lets say socket.io event to notify the frontend to update the UI.
Not only that but each new message that gets sent it actually calls a route which stores that message in database and once that's successful Then it emits a socket.io event to the frontend to fetch that message.
As you can imagine constantly calling routes like this Does induce small delays. Creating conversations, navigating, opening someones profile and especially sending messages, is NOT instantaneous. When you do it theres a small delay, giving the impression as if the app is SO large that it lags
But it doesnt lag, it just needs a few ms to store that in db so it can return the socket.io bidirectional message event. Which does make sense because what if the internet broke and the user immediately gets sent a message, but the message fails to get stored in database? Or db storage gets fucked or something else fails but socket.io works while db doesnt? The data then may be inconsistent. This approach fulfulls the single source of truth principle
So thats why im having mixed feelings about this approach particularly because of small delays. It is not instantaneous like whatsapp discord telegram signal viber etc the input UI freezes until the message is successfully sent
---
Of course this can be a UI/UX decision and can be handled differently even if the backend works like that.
My concern is is this approach valid?
My question is... I had an idea what if i emit socket.io event to send the message while in the background also call the route to store that message in db? This way not only would it work asynchronously but the message gets sent instantaneously, and if the backend fucks up to store it in db then the UI gets updated with message failed to get delivered, switching the socket.io into polling state. Is this a good (proper, efficient, better) way to do it or not?
rant