Exploring Real Time Communications

1. Long Polling

• How it works: The client sends a request to the server and waits for a response. The server holds the connection open until it has new data or until a timeout occurs. Once the data is ready, the server responds, and the client processes it. After receiving the response, the client immediately sends another request request to wait for more updates

• Use cases: Chat apps, notifications, real-time data feeds.

• Pros: Simulates real-time communication using HTTP, works in environments where WebSockets are not available

• Cons: Higher Latency compared to WebSockets, more resource-intensive due to repeated connections

• Real-life analogy: Calling a customer service hotline and being put on hold until a representative is available to speak to you.

2.Short Polling

• How it works: The client sends request to the server at fixed intervals (eg: every few seconds) to check for updates. The server responds immediately, regardless of whether new data is available.

• Use cases: Periodic updates, applications with infrequent changes.

• Pros: Simple to implement

• Cons: Inefficient because it generates many unnecessary requests, can increase server load, and may result in higher latency

• Real-life analogy: Asking someone every minute if they’ve finished a task, whether they have new information or not.

3.Web Sockets

• How it works: WebSockets establish a persistent, bi-directional TCP connection between the client and server after an initial HTTP handshake. Both the client and server can send and receive data continuously without needing to reopen connections

• Use cases: Real-time chat apps, online games, live data feeds(like stock market updates), collaborative tools

• Pros: Low Latency, full-duplex communication, more efficient for real-time communication.

• Cons: Requires WebSocket support on both client and server, more complex to implement than polling

• Real-life analogy: Having an open, continuous walkie-talkie connection with someone, allowing both sides to talk back and forth instantly.

4. Server-Sent Events(SSE)

• How it Works: SSE allows the server to push updates to the client over an open HTTP connection. The connection remains open, and the server sends data as it becomes available. Unlike WebSockets, communication is one-way: server to client

• Use cases: Real-time notifications, live data streams, dashboards, stock tickers.

• Pros: Easy to implement, native support in HTML5, low overhead.

• Cons: Unidirectional communication (only server to client), less flexible than WebSockets

• Real-life analogy: A radio station broadcasting live updates to listeners; you just keep the radio on and receive continuous updates.

5. Push Notifications

• How it works: Push notifications are messages sent from server to the user’s device, even when the application is not actively being used. For web applications, this is done through a service worker and a notification API that delivers messages to the browser or app.

• Use cases: Alerts, notifications, messages (like breaking news, chat notifications, or app updates)

• Pros: Can reach the user even when they are not actively using the app or website, ideal for alerts

• Cons: Requires specific infrastructure(push notification services), user opt-in required, not suitable for frequent updates

• Real-life analogy: Receiving a mail notification at your door about a package delivery even when you’re not expecting it.