Update🚀: Improved Security for Group Chats

Today, I implemented a new security feature on the chat package, if a member leaves a group, admins and owners will be restricted from re-adding them. This is designed to respect user preferences, ensuring that members have full control over their group participation

Update 🚀: Today I rolled out another feature - Group permissions 'allowMembersToSendMessages'

Admins now have the power to toggle whether group members can send messages. This feature is ideal for managing announcement-only groups, ensuring that only authorized participants(admins) can post updates.

Need Help Scaling Up Group Chat Notifications - Laravel

I initially broadcasted each message to a private channel (private-conversation.{id}), which worked well for one-on-one chats. Individual notifications were also sent via App.User.{id} to show updates outside the chat.

However, for group chats, this approach didn’t scale: each message triggered notifications to all members, quickly overloading the job queue. For instance, 20 messages in a group of 1,000 could result in 20,000 jobs. With 30 active users, it adds up to hundreds of thousands of jobs.

To tackle this, I’m considering a front-end subscription approach. On pages like ChatsList, users would subscribe to each conversation in a loop using Laravel Echo. This way, each new message requires only one event per conversation for updates, even outside the chat.

Trade-Off: This approach increases front-end complexity but drastically reduces backend load, enhancing efficiency.

Any thoughts or alternative ideas on this ?

Got it sorted! It was slow because after creating a job to NotifyParticipantsJob, the event NotifyParticipant was implementing shouldBroadcast, which queued the event.(which is unecessary since the NotifyParticipantsJob is already queued in backgroud) To fix it, I just implemented shouldBroadcastNow in the NotifyParticipant event, making it 95% faster. Now, 3K members receive updates instantly in just 2-5 seconds, compared to the former approach, which took 1-3 minutes! It's crazy seeing such speeds after days of optimization. I hope this approach sticks!

Which emoji picker layout would you prefer to use?

Layout 1 - Fixed at the bottom



Layout 2- Floating in corner



Any ideas?

Yes i noticed that . initially i followed the whatsApp-web approach of pushing content up, but when i checked WhatsApp-desktop app , it was using the floating emoji picker in the right corner, so now i am to trying figure out which approach to go with .However since this is a package i am thinking to just make it an opt in feature to choose floating or stacked layout

The Power of Timestamps: Solving Database Growth in Chat Applications



While optimizing a chat system, I encountered a scalability issue: when storing actions such as delete or clear on every message per user .(This approach meant users could delete chats while retaining messages for other participants ) i discovered it could lead to massive database growth for group Chats. For instance, in a group chat with 11,000 messages, if 100 users each clear the chat, this would generate 1.1 million records—one action per user for every message.

To solve this, I leveraged timestamps in the participants table. Instead of logging a separate action relation for each message, a single timestamp marks all messages as cleared for that user. By updating just one record per action, this approach reduces record creation drastically, saving storage space and enhancing performance.

There's nothing like the confidence boost when all tests pass!😎