Modern web apps need real-time communication—whether it's a chat app, stock ticker, or live sports commentary. There are multiple ways to implement it:

• HTTP Polling
• WebSockets
• Server-Sent Events (SSE)

In this blog, I’ll walk you through why I picked SSE for my commentary app, how it works, and how you can implement it using React and Node.js.

First, let’s understand that all the methods we use for real-time updates—Polling, WebSockets, and SSE—are based on the principles of Event-Driven Architecture (EDA). So before comparing them, it's important to know what EDA is and how it shapes real-time communication.

🧠 What is Event-Driven Architecture?
Event-Driven Architecture (EDA) is a design pattern where components of a system communicate through events. Instead of continuously requesting information, the system reacts to changes or triggers. For example, when a server emits a new event (like a notification), the frontend listens and responds to it—no need for repeated polling.

➡️ Want to dive deeper? Read this guide on Event-Driven Architecture.

Real-Time Communication Methods (With Examples)

1. HTTP Polling

What it is:

The client (frontend) sends HTTP requests at regular intervals (e.g., every 5 seconds) to check for updates on the server. The server responds with the latest data or status.

When to use it:

When real-time accuracy is important but you don't need instant updates, or when server push is not available.

Example use case:

✅ Checking UPI Payment Status:

When a user initiates a UPI payment, the frontend may not immediately know if the payment was successful.

So, the client sends a request to the server every few seconds to check the status. Once the server confirms that the payment is successful, the frontend can stop polling.

js
CopyEdit
// Polling example (client-side - pseudocode)
setInterval(() => {
  fetch('/api/payment-status')
    .then(res => res.json())
    .then(data => {
      if (data.status === 'success') {
        clearInterval(this);
        alert('Payment Successful!');
      }
    });
}, 5000); // Poll every 5 seconds

In the real world, we implement webhooks for payment confirmation, which involve server-to-server communication. However, in my case, I implemented a client-to-server approach, so HTTP polling would work.

2. WebSockets

What it is:

WebSocket is a full-duplex communication channel over a single long-lived connection. Both the client and server can send and receive data anytime after the connection is established.

When to use it:

When you need two-way communication, like real-time chat, collaborative tools (e.g., Google Docs), or multiplayer games.

Example use case:

🧑‍💬 Live Chat Application:

A chat app where both users can send and receive messages in real time. When one user sends a message, the other receives it instantly without refreshing or polling.

js
CopyEdit
// Client-side WebSocket example
const socket = new WebSocket('wss://your-chat-app.com/socket');

socket.onopen = () => {
  socket.send(JSON.stringify({ type: 'message', text: 'Hello!' }));
};

socket.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('Received message:', data.text);
};

3. Server-Sent Events (SSE)

What it is:

SSE allows the server to push real-time updates to the client over a single long-lived HTTP connection. Unlike WebSockets, communication is one-way (server → client only).

When to use it:

When the server needs to send continuous updates, like in dashboards, notifications, or live commentary apps—without requiring the client to ask.

Example use case:

🏏 Live Sports Commentary Feed:

A sports web app needs to show new commentary updates as they happen. The server sends updates automatically using SSE, and the frontend displays them instantly.

js
CopyEdit
// Client-side using EventSource
const eventSource = new EventSource('/events');

eventSource.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('New update:', data.comment);
};

Why I Chose SSE for My Commentary App

There are multiple ways to implement real-time updates in modern web applications. You can choose from WebSockets, HTTP Polling, and Server-Sent Events (SSE)—each with its own pros and cons.

In my case, I only needed unidirectional communication (from server to client), and I wanted a lightweight and easy-to-implement solution. That's why SSE was the perfect fit for my use case.

I recently built a sports commentary app where the server pushes live updates (like match events) to the frontend. With SSE, the browser maintains a connection to the server using the built-in EventSource API and receives updates without needing constant polling or a full WebSocket setup.

• One-way communication (server → client)
• Simple setup without installing extra libraries
• Browser-native support

👉 Check out the GitHub repository here. Feel free to ⭐️ the repo if you find it useful!

SSE checked all the boxes! I used EventSource on the frontend and Express on the backend.

🔧 Boosting SSE with Pub/Sub (Redis, Kafka, etc.)

SSE works great on its own for small apps. But when you need to scale across multiple servers or services, you can connect it to a pub/sub system like:

Redis (simple, in-memory pub/sub)

Kafka (great for distributed systems and large data streams)

This way, your backend can listen to events from Redis/Kafka and forward them to connected clients via SSE.

📌 Conclusion

SSE is often underrated but powerful for use cases like notifications, newsfeeds, or live commentary.

You don’t always need complex WebSocket setups. Sometimes, simple is better.

Choose your real-time tool based on your app's requirements—not just what's trendy.

Follow me on okrahul to stay connected with the developer community! Check out my recent blogs—they're packed with valuable insights. If you have any questions or doubts, feel free to drop a comment!