7 Real Problems I Faced While Building a Real-Time Chat Application

1. Managing Real-Time Messages Without Duplicates or Unexpected Updates

Building a real-time chat application presents challenges beyond simply creating a login system and displaying messages. Ensuring real-time messaging is reliable without duplicates or unexpected updates proved difficult. Firebase Firestore's real-time listeners allow an app to receive updates without constant data requests. However, as the application grew more complex, issues arose.

Switching between conversations could lead to unintended updates. Listener cleanup was necessary to handle asynchronous updates arriving after a component change. The issue wasn't with Firestore itself but the way real-time subscriptions were managed within React. React's useEffect cleanup mechanism proved crucial. Messages needed to be handled carefully, not simply added to an existing array.

Proper subscription management, predictable state updates, and handling of asynchronous events were vital for real-time applications. 2. Preventing Duplicate Conversations Between Two Users

Private conversations in ChatLoop included a friend-request system. Friend requests allowed users to send, accept, reject, or cancel requests. When two users became friends, they could start a private conversation. But this raised a question: What if both users tried to initiate the same conversation simultaneously? The application could create two separate chat threads for the same pair of users, complicating message history, unread counts, and conversation management.

To solve this, ChatLoop used a deterministic conversation ID based on the two users' identifiers. Regardless of the order in which users initiated the conversation, the same ID was generated. This ensured access to the correct chat and prevented duplicate conversations. However, proper database access rules were still necessary to restrict access to authorized conversations. 3. Making Unread Messages and Read Receipts Work Correctly

Unread message counts are a seemingly simple feature. A user receives a message, the unread counter increases, and when they open the conversation, the counter disappears. Implementing this correctly in a real-time environment turned out to be more complex than anticipated. Consider scenarios where multiple messages are received while viewing another conversation, new messages arrive while opening a conversation, two browser sessions are active for the same account, or a sender needs to know if the recipient has read a message.

The application requires tracking more than just message content; it must understand message relationships, recipients, active conversations, and read status. ChatLoop implemented conversation-level unread information and message status updates. When a message arrived, it determined whether it should count as unread for the recipient.

Opening a conversation also updated read state without incorrect changes to the sender's information. Visual indicators for message status, including read indicators, were added for user clarity. The key lesson was that delivering a message and reading a message are two different events; a message's existence in Firestore doesn't guarantee it has been read by the recipient.