Laravel notifications approach for live messasges
Hello all.
I am working on a Laravel Blade project where I need to implement a live messaging system using Munafio's cool plugin Chatify.
Everything works, I am able to connect Chatify to Pusher back and forth, receiving events etc. So my question is more of the best approach rather than how specifically to achieve it.
So I have a usual setup of Laravel where all my templates extend the default app.blade.php inside of which I have included the header markup for the live notifications. Since the idea is to have the notifications show for authenticated users on any of the templates, I could not just pull some data and pass it to the default layout as it is used for extending and not for navigating.
So my question is, how would you do the setup if your default temnplate contains the header markup for the notifications counter which when clicked would shoe either the last X-messages and the new ones will be in another color/bold (like FB styling) or to just show the new notifications (depending on the project coordinators decision).
1 Reply
Currently, the way i see this happening is:
1. Inside the default layout I will pull the array of x-messages or filter only the unread X messages and insert the total count inside the markup where the counter should be (of course a simple if statement will hide the counter if no new messages are to notify of).
2. Inside the NewMessageEvent (let's call like that my event file) I will pull from DB again the number of unread messages whcih will then be pushed to Pusher.com as data + the unread messages count variable.
3. From any of the templates that extend the default layout, since we have the pusher event code in the default, i will be able to listen for an event named NewMessasgeEvent (or whatever it got defined inside of my event file to broadcastAs()) and if i see such, I will pull the data.unread_messages_count and update the markup using JavaScript (or later i can switch to LiveWire once it is proven to be working as a proof of concept).
So with this approach I have thought to prevent the server overloading when there are 10-20K of users, to not pull the entire message data to show as markup in the dropdown but to use JSON and fire an even to pull the data only if the user clicks on the notifications menu.
As such I am in a need to have 2 DB queries - one in the default layout every time the page gets reloaded and 2 - when a new event is fired so to pass to the event at the web socket the total unread messages count to update.
Why I thought this would be the good approach was that when I register/authorize, I will pull the real data from DB and show the count properly (or hide the markup simply). If a new message is fired, I will update the counter again with the proper count.
Were I see a flow is if I click on a message and read it as if i read it, I should update the counter to either lower the count or hide it if a single event was. And for that I am thinking i should fire an event or listen for an existing from Chatify to update the counter again.
If you've done it in the past, what was your approach or if not, what would you suggest I should use as to:
1. Optimize the server load
2. Elegance and reading of code avoiding duplicate content
3. Minimize Pusher events (as we all know those are free but for a limit as of today for 5000 events per day).
And yes, I know I can use websocket inside my app but for now we aim at having v1 sooner than having the best app much later.
Stepping back from the coding board and coming back to it to attack at a different angle, I think I found the easiest and simplest solution already.
1, I will pull up the unread messages count inside the default layout (app.blade.php) and show the markup with the number.
2. If the unread messages count is zero, I will keep the value but hide the markup with the notifications counter.
3. Inside my event I will no longer broadcast the number of messages but just a plain notification with something like: NewMessageReceived.
4. On the receiver side (again inside the default layout wich would extend any other view) will add the channel of Pusher to listen to. So once a new event of type: NewMessageReceived is passed from Pusher servers to the app, I will read the current value of the notifications from the markup (that is why I will hide it and not remove from the markup) and from there either increase it accordingly.
With this approach I will have to add another event when the user opens his messages from the sender so that when this event is received in the default layout, the counter gets zeroed.
If anyone has a better idea, feel free to share, but I do not see any flaws (besides the end user tinkering the counter which could lead to an incorrect notifications count, however if he does, he won't expect a correct notifications count anyway.
And yes, to secure the comms, I am using the Chatify message structure for notifications channel of type: message-channel.id which is behind the middleware.