I ran into this firsthand while trying to build a live options dashboard. HTTP requests weren't going to cut it, and everything I was reading seemed overly complex until I went back to the basics. This article is the result of that process.

We'll cover Python's websockets library from scratch, then move into FastAPI, where many Python backends live. It's worth noting that WebSockets aren't the only solution for real-time communication. WebRTC may be a better fit depending on your use case, but understanding WebSockets is the right starting point before exploring further.

Table of Contents

1. WebSocket Connections and Methods

2. How to Build Your First WebSocket in Python

3. File Transfer Over WebSockets

4. How to Connect to an External WebSocket

5. WebSockets in FastAPI

6. How to Handle WebSocket Disconnections in FastAPI

7. Conclusion

WebSocket Connections and Methods

A WebSocket connection enables bi-directional communication between a client and a server. Once a connection is established, both sides can communicate freely without either having to ask first. This is different from a regular HTTP request, where the client always has to ask before the server can respond.

It looks something like this:

        CLIENT  <===== open connection =====>  SERVER

Note that a WebSocket URL is not a regular web page, so you can't "visit it" like a website. You need a client to talk to it.

Different frameworks provide different methods for handling WebSocket connections. With Python’s websockets library, for instance, a connection is automatically accepted the moment a client connects. With frameworks like FastAPI, you have to explicitly call await websocket.accept(), otherwise the connection gets rejected.

Let’s look at the core methods provided by Python’s websockets library:

1. websockets.serve(...):  starts a WebSocket server.

2. websockets.connect(...): connects to a WebSocket server.

3. websockets.send(...): sends a message from either side.

4. websockets.recv(): receives a message from client or server.

recv() takes no arguments because it's purely a waiting operation. It waits for the next message and returns it:

message = await websocket.recv()

How to Build Your First WebSocket in Python

Before we dive into frameworks, let’s explore Python’s websockets library. You’ll set up a simple server and client, and exchange messages over a WebSocket connection, giving you a solid foundation for understanding WebSockets under the hood.

Environment Setup

Run the following in your virtual environment to install or verify the WebSockets package:

pip install websockets
# or, to check if it's already installed:
pip show websockets

Create the WebSocket Server

Create server.py in your project folder, and paste this:

import asyncio
import websockets

async def handler(connection):
    print("Client connected")

    message = await connection.recv()
    print("Received from client:", message)
    await connection.send("Hello client!")


async def main():
    async with websockets.serve(handler, "localhost", 8000):
        print("Server running at ws://localhost:8000")
        #await asyncio.Future()  # runs forever
        await asyncio.sleep(30)

asyncio.run(main())

When this line executes:

async with websockets.serve(handler, "localhost", 8000):

The library opens a TCP socket on the specified host and port and waits for incoming clients. When one connects, it creates a connection object and passes it into your handler function.

The handler is required because it defines what the server does with each connection. The host and port arguments are also important. Both default to None – passing neither raises an error because the OS cannot bind a network server without a port.

You could pass port=0 to let the OS assign a free port automatically, but then you'd need an extra step to figure out which port was chosen, so the client can connect:

server.sockets[0].getsockname()

It’s simpler to specify both host and port explicitly, so the client knows exactly where the server is running.

Set Up the Client

Create client.py in the same folder and add this:

import asyncio
import websockets

async def client():
    async with websockets.connect("ws://localhost:8000") as websocket:
        await websocket.send("Hello server!")
        response = await websocket.recv()
        print("Server replied:", response)

asyncio.run(client())

Test the Connection

First, open a terminal and run server.py. You should see:

Server running at ws://localhost:8000

In a second terminal, run client.py. Messages should appear in both terminals confirming that the connection is active and both sides are communicating.

Note that the server must be running before you start the client – otherwise the client has nothing to connect to, and the connection will fail.

Keeping the server alive: a note on asyncio.Future()

In server.py, there’s a line currently commented out:

await asyncio.Future()

This keeps the server running indefinitely. For local development and testing however, await asyncio.sleep(30) is a simpler alternative. It keeps the server alive for a fixed period without running forever.

File Transfer Over WebSockets

WebSockets aren't limited to text. They support raw bytes too, which means you can send files directly over the connection. Here’s how a client can send a file to a server over a WebSocket connection:

Update server.py

async def file_handler(ws):
    print("Client connected, waiting for file...")
    file_bytes = await ws.recv()  # receive bytes
    with open("received_file.png", "wb") as f:
        f.write(file_bytes)
    print("File received and saved!")
    await ws.send("File received successfully!")

async def main():
    async with websockets.serve(file_handler, "localhost", 8000):
        print("Server running on ws://localhost:8000")
        await asyncio.sleep(50)  # keep server alive

asyncio.run(main())

The handler waits for incoming bytes with await ws.recv(); the websockets library automatically detects whether the incoming message is text or bytes, so no extra configuration is needed. Once received, the file is written to disk in binary mode ("wb") and the server sends a confirmation message back to the client.

Update client.py

import asyncio
import websockets

async def send_file():
    uri = "ws://localhost:8000"
    async with websockets.connect(uri) as ws:
        with open("portfolio-image.png", "rb") as f:  #open file in binary mode
            file_bytes = f.read()
        await ws.send(file_bytes)  # send bytes
        response = await ws.recv()
        print("Server response:", response)

asyncio.run(send_file())

The client opens the image in binary mode ("rb"), reads the entire file into memory as bytes, and sends it in a single ws.send() call. It then waits for the server's confirmation before closing the connection.

Test it

Add an image to your project folder and make sure the filename in client.py matches. Run server.py first, then client.py in a second terminal.

Once the transfer completes, the server saves the file as received_file.png in the same directory. You should see it appear in your workspace immediately.

This approach loads the entire file into memory before sending. For large files, it’s better to read and send them in chunks. But this is the easiest way to understand WebSocket byte transfer.

How to Connect to an External WebSocket

So far you've been connecting to servers you built yourself. But WebSocket clients can also connect to public servers. For example, a client can connect to Postman’s echo server:

import asyncio
import websockets

async def connect_external():
    uri = "wss://ws.postman-echo.com/raw"  # public WebSocket server
    async with websockets.connect(uri) as ws:
        print("Connected to external server!")

        # Send a message
        await ws.send("Hello external server!")
        print("Message sent")

        # Receive response
        response = await ws.recv()
        print("Received from server:", response)
asyncio.run(connect_external())

Notice the client connects to Postman’s echo server using the wss:// URI scheme instead of ws://. This indicates the connection is encrypted using TLS, similar to how https:// secures regular web requests.

An echo server returns exactly what you send it. So "Hello external server!" comes straight back as the response. It's a useful sandbox for testing your client-side WebSocket code without needing your own server.

WebSockets in FastAPI

FastAPI provides a WebSocket object (via Starlette under the hood) to manage real-time connections. You can define WebSocket endpoints just like HTTP routes, while Uvicorn handles the event loop – no manual asyncio server management needed. This makes FastAPI a natural fit for real-time projects, from chat apps to live dashboards and data feeds.

Before jumping into code, here's a quick reference of the core methods you'll be working with.

Accepting:

• await websocket.accept(): the accept() method must be called first, before anything else. Skip it and the connection gets rejected.

Sending:

• await websocket.send_text(data): sends a string.

• await websocket.send_bytes(data): sends binary data.

• await websocket.send_json(data): serializes and sends JSON.

Receiving:

• await websocket.receive_text(): waits for a text message.

• await websocket.receive_bytes(): waits for binary data.

• await websocket.receive_json(): receives and deserializes JSON.

• async for msg in websocket.iter_text(): iterates over incoming messages, exits cleanly on disconnect.

Closing:

• await websocket.close(code=1000): standard code for a normal closure. It accepts an optional “reason” argument.

Here's what the WebSocket lifecycle looks like in FastAPI:

Building a Simple Echo Server with FastAPI

As you saw with the Postman example, an echo server sends back the message a client provides. Let's build one with FastAPI.

1. Install FastAPI:

pip install "fastapi[standard]"

2. Update server.py:

from fastapi import FastAPI, WebSocket

app = FastAPI()

@app.websocket("/ws")
async def websocket_endpoint(websocket: WebSocket):
    await websocket.accept()
    data = await websocket.receive_text()
   
    await websocket.send_text(f"You said: {data}")

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="127.0.0.1", port=8000)

A few things to note here compared to the plain websockets library:

• WebSocket endpoints are defined with @app.websocket("/ws") just like an HTTP route.

• await websocket.accept() is required before anything else. FastAPI won't accept connections without it.

• Uvicorn handles the event loop and server startup for you via the if name == "__main__" block. No asyncio.run() or asyncio.Future() needed.

3. Update client.py:

async def test_client():
    uri = "ws://127.0.0.1:8000/ws"
    async with websockets.connect(uri) as ws:
        await ws.send("Hello FastAPI server!")
        response = await ws.recv()
        print("Server replied:", response)

asyncio.run(test_client())

Since the FastAPI server isn't secured with TLS, the client URI uses ws:// instead of wss://. Make sure to match the host and port from your server code.

4. Interact with the echo server:

Start server.py, then run client.py in another terminal. The server terminal should show the echoed message.

How to Handle WebSocket Disconnections in FastAPI

Clients will inevitably disconnect in real-time applications, sometimes intentionally, sometimes unexpectedly. If not handled properly, this can crash your server or leave it in a broken state.

The WebSocketDisconnect exception in FastAPI is raised whenever a client unexpectedly closes the connection, allowing the server to handle disconnects gracefully, log the event, and clean up resources without crashing.

Here’s an example:

@app.websocket("/ws")
async def websocket_endpoint(ws: WebSocket):
    await ws.accept()
    try:
        while True:
            data = await ws.receive_text()
   
            if "bye" in data or "quit" in data:
                await ws.send_text("Closing connection")
                await ws.close(code=1000, reason="Server requested close")  
                break
            await ws.send_text(f"I got your request: {data}")
    except WebSocketDisconnect:
        print("Client disconnected")  # connection already closed

The server runs a continuous loop waiting for messages. If the client message contains "bye" or "quit", the server responds, calls await ws.close(code=1000), and breaks out of the loop cleanly.

But if the client disconnects unexpectedly, WebSocketDisconnect is caught by the except block and the server moves on without crashing. At this point the connection is already closed on the client side, so calling ws.close() inside the except block is unnecessary.

Conclusion

WebSockets make real-time communication possible by keeping a persistent connection open between client and server. Starting with Python’s websockets library helps clarify how the protocol works under the hood, while frameworks like FastAPI provide the structure needed for production applications.

The parts that trip most people up early on are asyncio and FastAPI's explicit websocket.accept(). With asyncio, the question is usually why it's needed and why the server dies instantly without something keeping it alive. And it's easy to ignore websocket.accept() if you're coming from the plain websockets library where that happens automatically. Once those click, everything else follows naturally.

And although these concepts are closely related to what real-time means, the systems engineering definition is a bit different. A real-time system is not defined by how fast it is, but how predictable it is.

In this tutorial, you’ll learn about what real-time systems are, why most web applications are not real-time, and how to build a soft real-time system with tools you’re likely already familiar with: Go, React, and TypeScript.

At the end of this tutorial, we’ll build a live application that:

• processes time-sensitive events

• enforces deadlines

• drops work when it’s too late

• and visualises latency and missed deadlines in real-time

This article will help shape your mind the next time you’re building a real-time system.

Table of Contents

• Prerequisites

• What a Real-Time System Really Means

  • Types of Real-Time Systems

  • Why Most Web Apps Are Not Real-Time

• What We Are Going to Build

• System Architecture

• Why Go is a Good Fit for Our Use Case

  • Generating Events with Go

  • Deadline-aware Processing

  • Applying Back-Pressure

  • Streaming Events to the Browser

  • Consuming a WebSocket event (React + TypeScript)

  • Making React Real-Time Friendly

  • Creating the StatsBar Component

  • Creating the Events Table

  • Putting it All Together

• Final Thoughts

Prerequisites

This tutorial assumes that you have basic knowledge of Go, React, and WebSockets, particularly working with go-routines and consuming WebSockets events in React. If you don’t, I strongly recommend reviewing introductory tutorials before continuing so you can get the most out of this guide.

Helpful references include:

• Go Concurrency and Goroutines: The official Go blog covers concurrency patterns, including goroutines and channels, which are fundamental for writing concurrent Go code.

• WebSockets with Go: A thorough WebSocket tutorial using the popular gorilla/websocket package that shows how to set up a WebSocket server in Go and manage connections and messages. Here’s a Go WebSocket tutorial (with gorilla/websocket).

• WebSockets in React: A complete guide to WebSockets in React, explaining how to open and manage a WebSocket connection and handle incoming messages in components. Here’s a complete guide to WebSockets with React.

Technologies we’ll work with include:

• Go, for building our backend system and enforcing real-time guarantees

• React, for building a responsive frontend UI that displays streamed events

• Websocket, for low-latency delivery of data from the backend to the client

What a Real-Time System Really Means

In a traditional web application, correctness is measured by whether the system produced the right result. In a real-time system, correctness is measured by whether the system produced the right result before the deadline. If the result from the test is “No”, then the system has failed – even though the result is correct.

Types of Real-Time Systems

There are a few different types of real-time systems that you should be aware of, each with varying levels of strictness:

The majority of web-based real-time systems fall under the soft real-time category, and that’s exactly what we’ll build here.

Why Most Web Apps Are Not Real-Time

There are many reasons a system may not be real-time, and typically, even those marketed as real-time applications lack this guarantee.

Here’s why:

1. Websockets guarantee delivery, not timeliness

2. Massage queues are optimized for durability and throughput

3. Infinite buffering hides deadlines

4. User Interfaces (UIs) render when they can, not when they should

In other words, data will arrive eventually, but nothing enforces when it must be processed. That’s exactly the gap we’ll address in this tutorial.

What We Are Going to Build

In this tutorial, we’ll build a Deadline-Aware Live Event Monitor. You can think of it as a simplified real-time system for sensor data, trading events, alerts, or live telemetry.

Our app will have these features and constraints:

• Events are generated at a fixed rate

• Each event has a deadline

• The backend processes events only if they can be completed on time

• Late events are marked or dropped

• The frontend visualizes:

  • processing latency

  • missed deadlines

  • and system health

This will give us the required metrics to measure the real-time behavior of the system instead of guessing.

System Architecture

The high-level system architecture looks like this:

+-------------+     +------------------+     +----------------+
| Event       | --> | Deadline-Aware   | --> | WebSocket      |
| Generator   |     | Go Processor     |     | Server         |
+-------------+     +------------------+     +----------------+
                                                     |
                                                     v
                                           +----------------+
                                           | React Dashboard|
                                           +----------------+

Let’s break down the responsibilities:

Backend:

• Generates time-sensitive events

• Enforces deadline

• Applies back pressure

• Streams result to client (frontend)

Front End:

• Consumes real-time events

• Renders live metrics

• Remains responsive under load

Time is part of your Data Model

In a real-time system, time is explicit, not implicit. This means that each event processed includes:

• when it was created

• how long is it allowed to live, and

• when it was processed

Conceptually, a typical data model for an event looks like this:

{
  id: string
  createdAt: number
  deadlineMs: number
  processedAt?: number
  status: "on-time" | "late" | "dropped"
}

This is the mindset shift we hope to establish: in a real-time system, time is an essential component for your system that guarantees accuracy.

Why Go is a Good Fit for Our Use Case

Go is not a hard real-time language, but it’s excellent for soft real-time workloads. This is because of its:

• Cheap goroutines

• Structured concurrency with channels

• Deadline propagation via context.Context

• Simple runtime behavior

Most importantly, Go makes it easy to fail fast, which is essential for real-time systems.

Generating Events with Go

We’ll begin the development of our backend system by first defining the Event struct and creating a fixed-rate event generator function:

type Event struct {
        ID         string
        CreatedAt time.Time
        DeadlineMs  time.Duration
}

Here we’ve created an Event struct with the following properties:

• ID a unique identifier that helps in the management of each event processed by the system

• CreatedAt to track the time the event was created

• Deadline to help evaluate if the event met the assigned deadline or if it failed

Next, we’ll create the event generator startGenerator function:

func startGenerator(out chan<- Event) {
        ticker := time.NewTicker(50 * time.Millisecond)
        defer ticker.Stop()

        for range ticker.C {
                event := Event{
                        ID:         uuid.New().String(),
                        CreatedAt:  time.Now(),
                        DeadlineMs: 100,
                }


                select {
                case out <- event:
                default:
                  // Drop event when load peaks on the goroutine
                }
        }
}

Here, the event generator function accepts a Go channel as a parameter and uses a time.Ticker channel that fires every 50 milliseconds. On each tick, it creates a new Event with a uniqueID, a creation timestamp, and a deadline of 100 milliseconds (DeadlineMs: 100).

The generator then attempts to send the event into the output channel using a non-blocking send. If the channel is ready, the event is delivered immediately. If the channel is not ready (for example, because downstream consumers are slow or overloaded), the default case is executed, and the event is dropped.

Why do we have to drop the event here? Well, because hiding overload drops real-time guarantees. In short, dropping events is a deliberate backpressure strategy: it prevents overload from cascading through the system and protects latency bounds, which is often more important than completeness in real-time streaming systems.

Deadline-aware Processing

Next, we’ll create the processEvent function to handle the processing of the event. In Go, you can enforce deadlines by using context.WithTimeout like this:

func processEvent(event Event) string {
        ctx, cancel := context.WithTimeout(
                context.Background(),
                event.Deadline,
        )

        defer cancel()
        workDone := make(chan struct{})

        go func() {
                time.Sleep(50 * time.Millisecond)
                close(workDone)

        }()

        select {
        case <-workDone:
                return "on-time"
        case <-ctx.Done():
                return "late"
        }
}

Here we’ve intentionally ensured that work finishes before the deadline or it fails immediately.

In the processEvent function, each event is processed under a hard deadline enforced by a context with a timeout. The timeout duration is derived directly from the event’s deadline, meaning the event is only considered valid within the specified time window.

The actual work is executed in a separate goroutine, which simulates processing by sleeping for 50 milliseconds and then signaling completion by closing the workDone channel. We’ve intentionally structured this so that work either completes within the deadline or is treated as a failure immediately.

Applying Back-Pressure

In real-time systems, queues do not solve overload – they merely postpone it. When incoming events arrive faster than they can be processed, a queue continues to grow, increasing the time each event spends waiting.

Buffers can also hide failure. By absorbing excess load, they create the illusion that the system is healthy, even as processing delays grow beyond acceptable limits. This hidden degradation is dangerous because the system continues operating in a compromised state, producing results that are technically correct but operationally useless due to lateness.

As queues and buffers grow, latency increases silently. There is often no explicit error or signal that deadlines are being missed – the system simply becomes slower over time. In real-time systems, this silent latency growth is especially harmful because it violates the assumption that results are delivered within a known and bounded time window.

For these reasons, I strongly recommend that you use bounded channels. When the system becomes overwhelmed, bounded channels enforce back-pressure by refusing additional work. Instead of blocking indefinitely or growing unbounded queues, the system drops events when it cannot keep up.

This behavior makes failures visible. Dropped events are an explicit signal that the system is operating beyond its capacity. Rather than degrading unpredictably, the system degrades in a controlled and observable way. In this context, dropping events is a feature, not a bug, because it preserves latency guarantees for the events that do get processed and allows operators to detect, reason about, and respond to overload conditions immediately.

Streaming Events to the Browser

Next, we’ll build the Websocket broadcast system to push processed events to the frontend using the Gorilla Go websocket package (but feel free to use any package of your choice).

package main

import (
        "encoding/json"
        "net/http"
        "github.com/gorilla/websocket"
)

var upgrader = websocket.Upgrader{
        CheckOrigin: func(r *http.Request) bool {
                return true
        },
}

func wsHandler(out <-chan Event) http.HandlerFunc {
        return func(w http.ResponseWriter, r *http.Request) {
                conn, _ := upgrader.Upgrade(w, r, nil)
                defer conn.Close()
                for event := range out {
                        data, _ := json.Marshal(event)
                        conn.WriteMessage(websocket.TextMessage, data)
                }
        }
}

Here, we simply upgrade an incoming HTTP request to a WebSocket connection and continuously reads events from our Event channel we created earlier, serializing each event to JSON and broadcasting it to the connected client. It acts purely as a transport layer, pushing already-processed events to clients with low latency.

It’s important to note that WebSockets do not make a system real-time. WebSockets merely provide low-latency delivery from the backend to the client. The real-time guarantees are established earlier in the backend pipeline through deliberate design choices: fixed-rate event generation, explicit per-event deadlines, bounded queues, non-blocking sends, deadline-aware processing using contexts, and fail-fast behavior when deadlines are exceeded.

By the time an event is sent over a WebSocket, it has already either met its real-time constraints or been discarded. The WebSocket layer simply transports the result – it doesn’t enforce or create real-time behavior.

Consuming a WebSocket Event (React + TypeScript)

Up until now, we’ve been building the backend of our real-time event generator and broadcast system. In the next sections, we’ll build the frontend of the system using React and TypeScript.

We’ll start by initializing a WebSocket client to consume incoming events from the backend using the traditional WebSocket browser interface.

const socket = new WebSocket("ws://localhost:8080/ws");
socket.onmessage = (event) => {
  const data = JSON.parse(event.data);
  buffer.push(data);
};

Here we simply initialize a new WebSocket, passing along the WebSocket URL from the backend. You have to reference the same URL. Instead of rendering every message immediately, it’s recommended that you always batch updates.

Making React Real-Time Friendly

Next, let’s create a React useRealTimeEvents hook to handle streaming and processing of event broadcasts from the backend. Rendering on every message causes render storms, UI lag, and misleading dashboards. Instead, we render on animation frames.

import { useEffect, useRef, useState } from 'react';
import type { RealTimeEvent } from 'types/types';

function useRealTimeEvents() {
  const [events, setEvents] = useState<RealTimeEvent[]>([]);
  const buffer = useRef<RealTimeEvent[]>([]);

  useEffect(() => {
    const ws = new WebSocket('ws://localhost:8080/ws');
    ws.onmessage = (msg) => {
      buffer.current.push(JSON.parse(msg.data));
    };

    let raf: number;

    const flush = () => {
      if (buffer.current.length > 0) {
        const pendingEvents = buffer.current.slice(0);

        setEvents((prev) => {
          const next = [...prev, ...pendingEvents];
          return next.slice(-50);
        });
      }
      raf = requestAnimationFrame(flush);
    };

    raf = requestAnimationFrame(flush);

    return () => {
      ws.close();
      cancelAnimationFrame(raf);
    };
  }, []);
  return events;
}

export default useRealTimeEvents;

The UI is part of the real-time system. It’s important to note that the system broadcasts messages to the frontend in milliseconds. This behavior already crosses the web browser refresh rate threshold.

In certain situations, you might even guess that the use of setTime should come in handy here. And that’s a good alternative – but there’s a better solution: using requestAnimationFrame().

The requestAnimationFrame() takes in a callback function flush which is regulated by the animation frame, ensuring that we don’t cross the refresh rate threshold before the next repaint. You can learn more about it requestAnimationFrame() here.

Creating the StatsBar Component

Next, let’s create a little statusBar component to show events that arrived within the deadline and those that came in late.

Create a new component StatsBar and add the code below:

import { type FC } from 'react';
import type { RealTimeEvent } from 'types/types';

const StatsBar: FC<{ events: RealTimeEvent[] }> = ({ events }) => {
  const late = events.filter((e) => e.status === 'late').length;
  return (
    <div className="flex flex-row gap-2 bg-gray-500 w-full py-2.5 px-2">
      <strong>Events: {events.length} | </strong>
      <strong>Late: {late}</strong>
    </div>
  );
};

export default StatsBar;

Here we are creating a minimal stats component to show the total number of events and those that arrived late by looping through the incoming event list whose statuses are late.

Creating the Events Table

Next, we’ll create a EventTable component to display the events.

import { type FC } from 'react';
import type { RealTimeEvent } from 'types/types';

export const EventsTable: FC<{ events: RealTimeEvent[] }> = ({ events }) => {
  const formatDate = (date: string) => new Date(date).toLocaleString();
  return (
    <div className="w-full">
      <div className="relative overflow-x-auto bg-neutral-primary-soft shadow-xs rounded-base border border-default">
        <table className="w-full text-sm text-left rtl:text-right text-body">
          <thead className="text-sm text-body bg-neutral-secondary-soft border-b rounded-base border-default">
            <tr>
              <th scope="col" className="px-6 py-3 font-medium">
                ID
              </th>
              <th scope="col" className="px-6 py-3 font-medium">
                Satus
              </th>
              <th scope="col" className="px-6 py-3 font-medium">
                Created At
              </th>
              <th scope="col" className="px-6 py-3 font-medium">
                Processed At
              </th>
              <th scope="col" className="px-6 py-3 font-medium">
                Deadline
              </th>
            </tr>
          </thead>
          <tbody>
            {events.map((e, i) => (
              <tr
                key={e.id + i}
                className="bg-neutral-primary border-b border-default"
              >
                <td className="px-6 py-4">{e.id.slice(0, 6)}</td>
                <td className="px-6 py-4">{e.status}</td>
                <td className="px-6 py-4">{formatDate(e.createdAt)}</td>
                <td className="px-6 py-4">{formatDate(e.processedAt)}</td>
                <td className="px-6 py-4">{e.deadlineMs}</td>
              </tr>
            ))}
          </tbody>
        </table>
      </div>
    </div>
  );
};

Here we loop through all incoming events and display the event’s id, status, and deadline. These metrics will help us gain insight into the performance of our real-time events broadcast system.

Putting it All Together

At this point, we have implemented a complete, end-to-end real-time application that connects a deadline-aware Go backend to a lightweight React frontend. On the backend, events are generated at a fixed rate, processed under explicit deadlines, and dropped when the system is under load to preserve real-time guarantees. Only events that meet these guarantees are forwarded to connected clients via WebSocket broadcast.

On the frontend, we’ve built the useRealtimeEvents hook to establish a persistent WebSocket connection and continuously stream events from the backend as they arrive. The StatsBar component provides immediate visibility into the system’s behavior by summarizing key characteristics of the event stream, while the EventTable component renders individual events in the order they are received. Together, these components clearly mirror the behavior of the system under normal conditions in real-time.

With both the frontend and backend components in place, the application now functions as a real-time monitor. The backend enforces timelines and correctness, and the frontend simply reflects the outcome of those decisions in real-time. There is no buffering or replay logic on the client side – what’s displayed on the UI is exactly what the system was able to process within the specified deadline.

Finally, replace your Welcome component with the code below to display the StatusBar and EventsTable component.

import { useRealtimeEvents } from "./hooks/useRealtimeEvents";
import { StatsBar } from "./components/StatsBar";
import { EventTable } from "./components/EventTable";

export default function App() {
  const events = useRealtimeEvents();

  return (
    <div>
      <h1>Real-Time Event Monitor</h1>
      <StatsBar events={events} />
      <EventTable events={events} />
    </div>
  );
}

The React frontend is scaffolded using create-react-app, but the same approach can be used for other frameworks, such as Next.js or Vite. The complete source code, including the frontend and backend, is available in the repository here. You can reach out to me on the X platform if you need my assistance.

Final Thoughts

If you’ve followed this tutorial up to this point, congratulations! You’ve learnt the most critical part of building resilient deadline-aware real-time systems.

Remember, real-time systems are not about being fast, but about how predictable they are. You don’t need a Real-Time Operating System (RTOS), a PhD, or specialized hardware to start learning real-time design.

All you need to excel is to respect time, bound your resources, and accept that sometimes, dropping data is the correct behavior. If you understand that, you’re already thinking like a real-time systems engineer.

In this article, you’ll learn about WebSockets and Server-Sent Events (SSE), two powerful communication protocols that ensure seamless, real-time interactions in modern web applications.

By examining their differences, advantages, and use cases, you’ll gain a clear understanding of how to choose the right protocol to optimize scalability and performance. This article also includes simple example implementations using Node.js, allowing you to see these technologies in action.

To help you solidify your knowledge further, we’ll conclude with practical project recommendations, offering hands-on opportunities to apply what you’ve learned.

Table Of Contents

1. What is a WebSocket?

2. Advantages and Disadvantages of WebSockets

3. Use Cases for WebSockets

4. How to Create a WebSocket Server with Node.js

5. What are Server-Sent Events (SSE)?

6. Advantages and Disadvantages of Server-Sent Events

7. Use Cases for SSE

8. How to Implement Server-Sent Events using Node.js

9. WebSockets vs Server-Sent Events

10. Which is Better: Server-Sent Events or WebSockets?

11. Conclusion

What is a WebSocket?

In short, a WebSocket is a communication protocol that enables full-duplex, low-latency, event-driven connections between the server and the browser. In case you’re not familiar, full-duplex refers to the ability to send and receive data simultaneously between a client (like a web browser) and a server over a single connection.

Unlike HTTP, which operates in a request-response model, WebSockets enable persistent and continuous data exchange. This means that the data is exchanged in real-time, and pulling it from the server is unnecessary each time.

The WebSockets protocol was formalized in 2011 by the IETF through RFC 6455 and is now supported by all major browsers (Chrome, Edge, Safari, and so on).

Although WebSockets differ from HTTP, both protocols operate on the OSI model’s Application Layer (layer 7) and rely on TCP/IP at the Transport Layer (layer 4). The OSI (Open Systems Interconnection) model is a conceptual framework used to understand network communication. It divides the network into 7 layers, each responsible for a specific function, from physical data transmission to application-level interactions.

Similar to HTTP and HTTPS, WebSockets have a unique set of prefixes:

• ws: indicates an unencrypted connection without TLS and should not be opened from HTTPS-secured sites.

• wss: indicates an encrypted connection secured by TLS and shouldn’t be opened from HTTP (non-secure) sites.

How Do WebSockets Work?

As I mentioned earlier, WebSockets establish a persistent, bidirectional connection between the client and the server. The process begins with an HTTP handshake initiated by the client, where the client requests a WebSocket connection by sending a specific header to the server. If the server accepts the request, it responds with a status code 101 confirming the upgrade to a WebSocket connection.

Once the connection is established, the WebSocket protocol takes over, and both the client and the server can send and receive data at any time without the need for repeated handshakes. This continuous connection allows real-time communication with minimal latency, as data is exchanged immediately without waiting for additional requests.

The WebSocket connection remains open until either the client or server decides to close it. This ensures efficient and fast data exchange, making it ideal for real-time applications like chat systems, online gaming, or live data feeds.

Advantages of WebSockets

• Full-duplex connection: both client and server can send and receive data simultaneously.

• Low latency: since WebSockets maintain an open connection, they ensure minimal delay in data transfer by eliminating the overhead of repeatedly establishing and tearing down connections, ensuring minimal delay in data transfer.

• Reduced bandwidth usage: unlike HTTP requests, which include headers for every request, WebSockets only require a single handshake, resulting in smaller data packets and reduced bandwidth consumption.

• Cross-Platform Compatibility: as stated earlier, WebSockets are supported by most modern browsers and programming frameworks, which ensures broad applicability.

Disadvantages of WebSockets

• Complexity in implementation: WebSockets require a dedicated server and a special protocol.

• Vulnerability to attacks: Without proper security (wss prefix) and authentication mechanisms, WebSockets are susceptible to cross-site WebSocket hijacking (CSWSH) and man-in-the-middle (MITM) attacks.

• No built-in security: Unlike HTTP, WebSockets do not inherently support request-response headers for additional security. Thus, it’s necessary to implement token-based authentication or other secure methods manually.

Use Cases for WebSockets

WebSockets have revolutionized how applications deliver real-time communication. This protocol powers various industries by enabling low-latency, bidirectional data flow. Let’s talk about some good use cases for WebSockets:

1. Chat Applications

WebSockets’ full-duplex connection ensures that messages are delivered instantly and without interruptions, making them the perfect choice for real-time communication. This technology powers platforms like Slack, Discord, and various live customer support chat systems, providing seamless and efficient interactions.

2. Online Gaming

WebSockets are essential for fast-paced online games like Clash Royal, where real-time communication between players and servers is crucial. By maintaining a persistent, two-way connection, WebSockets allow immediate transmission of actions, such as moves or attacks, ensuring that all players experience seamless gameplay without lag.

3. Real-Time Dashboards

Tools like Datadog and e-commerce platforms use WebSockets to ensure system metrics, sales, and inventory data are always current, eliminating manual refreshes and enhancing user experience.

WebSockets also excel at handling big data, streaming, and visualizing large volumes of information with low latency. This makes them the perfect choice for industries such as finance, healthcare, and logistics, where real-time insights are essential for effective decision-making.

An example is DataTableDev, a grid prototype capable of working with massive data volumes, demonstrating WebSockets’ potential in real-time data processing.

How to Create a WebSocket Server with Node.js

Before setting up a simple WebSocket server with Node.js to handle secure connections, you’ll need a TLS certificate to ensure the communication is encrypted. You can acquire one from a trusted Certificate Authority (CA) like Let's Encrypt or use a self-signed certificate for testing.

Below is the complete implementation of a WebSocket Secure (WSS) server using Node.js:

We’ll start on the server-side. Firstly, let’s import the required modules:

const https = require('https');  // Module for creating an HTTPS server
const fs = require('fs');        // Module to read files (used to load TLS certificates)
const WebSocket = require('ws'); // WebSocket library to handle WebSocket connections

Next, we’ll load TLS certificates for secure communication (wss://).

const serverOptions = {
  cert: fs.readFileSync('cert.pem'), // Load the TLS certificate for HTTPS encryption
  key: fs.readFileSync('key.pem'),   // Load the private key associated with the certificate
};

serverOptions reads the TLS certificate and private key from files (cert.pem and key.pem) and holds them. These are essential for establishing secure communication using the wss:// protocol since they enable encryption for data transmitted between the server and the client.

Since the WebSocket server runs on top of the HTTPS server, we first create and initialize the HTTPS server using the serverOptions, and then set up the WebSocket server.

// Create the HTTPS server with the loaded certificates and initialize it with TLS options
const httpsServer = https.createServer(serverOptions); 
// Create a WebSocket server that runs on top of the HTTPS server
const wss = new WebSocket.Server({ server: httpsServer });

Now it's time to define the behavior when a new WebSocket connection is established. You'll need to handle incoming messages from the WebSocket client, send a response back, and manage the disconnection process. In this tutorial, we'll keep it simple by printing the received data to the console.

// Define the behavior when a new WebSocket connection is established
wss.on('connection', (ws) => {
  console.log('Client connected');

  // Handle incoming messages from the WebSocket client
  ws.on('message', (message) => {
    console.log(`Received: ${message}`); 
    ws.send(`Server received: ${message}`); // Send a response back to the client
  });

  // Handle when a client disconnects
  ws.on('close', () => {
    console.log('Client disconnected');

  // Send an initial message to the client when the connection is established
  ws.send('Welcome to the secure WebSocket server!');
});

Last but not least, you need to define the port where the HTTPS WebSocket server will listen for incoming connections. In this example, we use a port 8080. After that, we start the HTTPS server and make it listen on the specified port. Once the server is up and running a log message will be printed to confirm that the secure WebSocket server is ready.

// Define the port where the HTTPS WebSocket server will listen for incoming connections
const PORT = 8080;

// Start the HTTPS server and begin listening on the specified port
httpsServer.listen(PORT, () => {
  console.log(`Secure WebSocket server running at wss://localhost:${PORT}`); // Log a message when the server starts
});

And that’s it for the server-side part. Your full code should look like this:

// Import required modules
const https = require('https');  // Module for creating an HTTPS server
const fs = require('fs');        // Module to read files (used to load TLS certificates)
const WebSocket = require('ws'); // WebSocket library to handle WebSocket connections

// Load TLS certificates for secure communication (wss://)
const serverOptions = {
  cert: fs.readFileSync('cert.pem'), // Load the TLS certificate for HTTPS encryption
  key: fs.readFileSync('key.pem'),   // Load the private key associated with the certificate
};

// Create the HTTPS server with the loaded certificates and initialize it with TLS options
const httpsServer = https.createServer(serverOptions); 
// Create a WebSocket server that runs on top of the HTTPS server
const wss = new WebSocket.Server({ server: httpsServer }); 

// Define the behavior when a new WebSocket connection is established
wss.on('connection', (ws) => {
  console.log('Client connected'); 

  // Handle incoming messages from the WebSocket client
  ws.on('message', (message) => {
    console.log(`Received: ${message}`); 
    ws.send(`Server received: ${message}`); // Send a response back to the client
  });

  // Handle when a client disconnects
  ws.on('close', () => {
    console.log('Client disconnected'); 
  });
  // Send an initial message to the client when the connection is established
  ws.send('Welcome to the secure WebSocket server!');
});

// Define the port where the HTTPS WebSocket server will listen for incoming connections
const PORT = 8080;

// Start the HTTPS server and begin listening on the specified port
httpsServer.listen(PORT, () => {
  console.log(`Secure WebSocket server running at wss://localhost:${PORT}`); // Log a message when the server starts
});

To run the created server with Node.js, type the following line into Command Prompt / Terminal:

node wss-server.js

Connect to the server using a WebSocket client or browser console at wss://localhost:8080.

Once the connection is established, the client can send and receive messages. Now well look at a simple example of how to receive and send messages on the client side.

To start, let’s define a basic HTML structure:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>WebSocket Client</title>
</head>
<body>
  <h1>WebSocket Client</h1>
  <div id="messages"></div>
  <input type="text" id="messageInput" placeholder="Type a message">
  <button onclick="sendMessage()">Send Message</button>

  <script>
    <!-- JS code goes here -->
  </script>
</body>
</html>

The <button> element has an onclick event that triggers the sendMessage() function when clicked. Before we dive into the function, let's first establish a WebSocket connection to the server. We'll also define event listeners to handle the following:

1. When the WebSocket connection is successfully established.

2. When a message is received from the server.

These event listeners will ensure that we can interact with the server and handle incoming data in real time.

    // Establish a WebSocket connection to the server
    const socket = new WebSocket('wss://localhost:8080'); 

    // Event listener for when the WebSocket connection is established
    socket.addEventListener('open', () => {
      displayMessage('Connected to the WebSocket server');

    // Event listener for when a message is received from the server
    socket.addEventListener('message', (event) => {
      displayMessage(`Server: ${event.data}`); // Display the message received from the server
    });

To display the message on the user interface, we've created a function called displayMessage. Here's how it's defined:

// Function to display messages in the message container
function displayMessage(message) {
      const messageDiv = document.getElementById('messages'); // Get the div where messages will be displayed
      const newMessage = document.createElement('p'); // Create a new paragraph element for the new message
      newMessage.textContent = message; // Set the text content of the paragraph to the message
      messageDiv.appendChild(newMessage); // Add the new paragraph to the message container
}

Now, it’s time to define the sendMessage() function. Firstly, we retrieve a message and then send it to the WebSocket server using the socket.send() method. This transmits the message over the WebSocket connection established earlier, allowing the server to receive it. Next, on the UI, we display the message and clear the input field.

Thus, the code looks the following way:

    // Function to send a message to the server
    function sendMessage() {
      const message = document.getElementById('messageInput').value; // Get the message from the input field
      socket.send(message); // Send the message over the WebSocket connection
      displayMessage(`You: ${message}`); // Display the message in the UI as sent by the user
      document.getElementById('messageInput').value = ''; // Clear the input field after sending the message
    }

The final step is to set the event listener for when the WebSocket connection closes. To keep it simple, we will log a message to the console.

 socket.addEventListener('close', () => {
      console.log('Disconnected from the WebSocket server'); 
 });

This is what the client-side part looks like:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>WebSocket Client</title>
</head>
<body>
  <h1>WebSocket Client</h1>
  <div id="messages"></div>
  <input type="text" id="messageInput" placeholder="Type a message">
  <button onclick="sendMessage()">Send Message</button>

  <script>
    // Establish a WebSocket connection to the server
    const socket = new WebSocket('wss://localhost:8080'); // Connect to WebSocket server 

    // Event listener for when the WebSocket connection is established
    socket.addEventListener('open', () => {
      displayMessage('Connected to the WebSocket server');

    // Event listener for when a message is received from the server
    socket.addEventListener('message', (event) => {
      displayMessage(`Server: ${event.data}`); // Display the message received from the server
    });

    // Function to send a message to the server
    function sendMessage() {
      const message = document.getElementById('messageInput').value; // Get the message from the input field
      socket.send(message); // Send the message over the WebSocket connection
      displayMessage(`You: ${message}`); // Display the message in the UI as sent by the user
      document.getElementById('messageInput').value = ''; // Clear the input field after sending the message
    }

    // Function to display messages in the message container
    function displayMessage(message) {
      const messageDiv = document.getElementById('messages'); // Get the div where messages will be displayed
      const newMessage = document.createElement('p'); // Create a new paragraph element for the new message
      newMessage.textContent = message; // Set the text content of the paragraph to the message
      messageDiv.appendChild(newMessage); // Add the new paragraph to the message container
    }

    // Event listener for when the WebSocket connection is closed
    socket.addEventListener('close', () => {
      console.log('Disconnected from the WebSocket server'); 
    });
  </script>
</body>
</html>

What are Server-Sent Events (SSE)?

Server-Sent Events (SSE) is a technology that enables a web server to push updates to a web page. As part of the HTML5 specification, it functions similarly to WebSockets by using a single, long-lived HTTP connection to deliver data in real-time.

The concept of SSE originated in 2004, with the Opera team taking the first steps towards implementation in 2006. One of the main limitations of SSE in the early stages was the connection cap imposed by HTTP/1.1, which restricted the number of simultaneous connections a client could establish with a server. But with the introduction of HTTP/2, this limitation was removed. HTTP/2 allows multiple data streams to flow over a single connection through multiplexing, enabling more efficient and scalable communication for SSE.

Server-sent events (SSE) rely on two fundamental components:

• EventSource: An interface defined by the WHATWG specification and implemented by modern browsers. It enables the client (typically a browser) to subscribe to server-sent events.

• EventStream: A protocol that specifies the plain-text format servers must use to send events, ensuring compatibility with the EventSource client for seamless communication.

As the specification outlines, events can include arbitrary text data and an optional ID and are separated by newlines. Also, SSE events have a dedicated MIME type: text/event-stream. A MIME type (Multipurpose Internet Mail Extensions type) is a standard that indicates the nature and format of a file or data, allowing the browser or server to properly interpret and handle it.

How do Server-Sent Events Work?

Server-sent events (SSE) work by establishing a persistent, one-way communication channel from the server to the client over a standard HTTP connection. The client initiates the connection by creating an EventSource object, which sends a request to the server to start streaming data. Once the server receives this request, it responds by sending a continuous stream of updates in a specific text/event-stream format. The client listens for these events, automatically handling any reconnections if the connection is lost.

SSE is ideal for applications that require real-time updates from the server, such as live news feeds or notifications, as it ensures a constant flow of information with minimal overhead.

Advantages of Server-Sent Events

• Polyfill capability: Server-sent events (SSE) can be implemented using JavaScript in browsers that don’t natively support them. This ensures backward compatibility by leveraging the standard SSE interface instead of creating a custom alternative.

• Automatic reconnection: SSE connections are designed to reconnect automatically after interruption. Thus, they reduce the need for extra code to handle this essential functionality.

• Firewall-friendly: SSEs work seamlessly with corporate firewalls that perform packet inspection, making them a reliable choice for enterprise applications.

Disadvantages of Server-Sent Events

• Data format restrictions: SSE is restricted to transmitting messages in UTF-8 format, as it does not support binary data.

• Connection limits: Browsers cap the number of simultaneous SSE connections to six per client. This limitation becomes problematic when multiple tabs require active SSE connections. For more details and potential workarounds, refer to this StackOverflow thread: Server-Sent Events and browser limits.

• One-way communication: SSE supports only server-to-client messaging, making it ideal for read-only real-time applications like stock tickers. However, this unidirectional nature can be a constraint for more interactive real-time applications.

Use Cases for SSE

Server-sent events are widely used in applications where real-time data delivery is crucial. SSE enables the server to push updates to the client automatically, making it ideal for applications that require live information streams. From news feeds to financial dashboards, SSE ensures that users receive the latest content without constant page refreshes.

Here are some common use cases for using SSE:

1. Social Media Feeds

Social media platforms leverage SSE to push new posts instantly, likes, and comments to users’ feeds, providing a more dynamic and engaging user experience. A great example is Twitter’s (X’s) real-time feed implementation, which allows them to push real-time updates to the browser.

2. Enterprise Monitoring System

SSE enables financial monitoring systems and other real-time applications to deliver live data updates efficiently. For instance, Netflix’s open-source Hystrix, a well-known component for microservice monitoring and circuit breaking, includes a web dashboard that displays real-time performance metrics and circuit status. This dashboard uses SSE to push performance data in real-time, ensuring that users can monitor the health and performance of microservices as they happen. The dashboard leveraging SSE provides an efficient, low-latency solution for updating performance data without needing constant manual refreshing or polling.

3. Generative AI

SSE technology plays a key role behind the scenes when interacting with Generative AI chatbots like ChatGPT and Gemini. For instance, when a user requests ChatGPT to write an article on a specific topic, the server starts processing the request and generates the article progressively, often in chunks rather than all at once.

During this process, ChatGPT’s server utilizes SSE to push each part of the article to the client in real-time, allowing the user to see the content appear as it is being generated.

How to Implement Server-Sent Events using Node.js

In this section, we’ll explore how to implement SSE using Node.js, a popular JavaScript runtime, to push updates to the client in real-time. We’ll set up a basic server and send live data to the browser using SSE.

We’ll start with the client-side (HTML/JavaScript). First, we’ll create a new EventSource object to listen for events from the server.

const evtSource = new EventSource("sse-demo.js");

The URL "sse-demo.js" is the path to the server-side script that will generate the events. But if the event generator script were hosted on a different origin, we would need to provide an additional configuration for cross-origin requests.

// If the event generator script is hosted on a different origin (cross-origin request):
const evtSource = new EventSource("//api.example.com/sse-demo.js", {
  withCredentials: true,  // Sends cookies, authorization headers with the request to the server
});

This version ensures that cookies and authorization headers are sent with the request, enabling secure communication and making sure that credentials can be included in cross-origin requests. withCredentials: true ensures that authentication is handled correctly if needed.

Next, let’s set up an event listener to handle the message when it is received. To keep things simple, we will display the message on the user interface by adding it as a new list item.

// When a message event is received
evtSource.onmessage = (event) => {
  // Create a new list item element to display the message
  const newElement = document.createElement("li");

  // Get the reference to the unordered list element where messages will be displayed
  const eventList = document.getElementById("list");

  // Set the text content of the new list item to the message received
  newElement.textContent = `message: ${event.data}`;

  // Append the new list item to the event list (ul) in the HTML
  eventList.appendChild(newElement);
};

Let's also add an event listener for a custom "ping" event. Again, we will simply add new data to the list and display it on the page. Thus, when the custom event is received, a new list item (<li>) is created.

The event data, which contains a time property, is parsed from JSON, and the time is displayed in the list item. This new list item is then appended to an unordered list (<ul>) in the HTML, allowing the "ping" event data to be shown on the user interface.

// Add an event listener for a custom event type, "ping"
evtSource.addEventListener("ping", (event) => {
  // Create a new list item element to display the ping event
  const newElement = document.createElement("li");

  // Get the reference to the unordered list element where ping events will be displayed
  const eventList = document.getElementById("list");

  // Parse the event data as JSON (assuming it contains a time property)
  const time = JSON.parse(event.data).time;

  // Set the text content of the new list item to display the ping time
  newElement.textContent = `ping at ${time}`;

  // Append the new list item to the event list (ul) in the HTML
  eventList.appendChild(newElement);
});

Make sure that your code for the client-side part looks like this:

// Create a new EventSource to listen for events from the server
const evtSource = new EventSource("sse-demo.js");

/* If the event generator script is hosted on a different origin (cross-origin request):
const evtSource = new EventSource("//api.example.com/sse-demo.js", {
  withCredentials: true,  // Sends cookies, authorization headers with the request to the server
});
*/
// When a message event is received
evtSource.onmessage = (event) => {
  // Create a new list item element to display the message
  const newElement = document.createElement("li");

  // Get the reference to the unordered list element where messages will be displayed
  const eventList = document.getElementById("list");

  // Set the text content of the new list item to the message received
  newElement.textContent = `message: ${event.data}`;

  // Append the new list item to the event list (ul) in the HTML
  eventList.appendChild(newElement);
};

// Add an event listener for a custom event type, "ping"
evtSource.addEventListener("ping", (event) => {
  // Create a new list item element to display the ping event
  const newElement = document.createElement("li");

  // Get the reference to the unordered list element where ping events will be displayed
  const eventList = document.getElementById("list");

  // Parse the event data as JSON (assuming it contains a time property)
  const time = JSON.parse(event.data).time;

  // Set the text content of the new list item to display the ping time
  newElement.textContent = `ping at ${time}`;

  // Append the new list item to the event list (ul) in the HTML
  eventList.appendChild(newElement);
});

Now, let’s code the server-side part with Node.js and Express.js. Express is a minimal and flexible web application framework for Node.js. It simplifies the creation of server-side applications by providing robust features like routing, middleware support, and handling HTTP requests and responses. It helps streamline the development of web APIs and websites, making it perfect for our tutorial.

Note that you’ll need to go to the official Express.js documentation and install it on your machine if you don’t have it installed already.

Then, head over to the IDE and import the Express module, which allows us to create an instance of the Express application.

// Import the Express module
const express = require('express');
// Create an instance of the Express application
const app = express();

It is considered good practice to specify the port number at the top of the file to make it easy to configure and modify later. This approach improves code readability and maintainability, allowing you to quickly change the port number without searching through the entire file. It also enables better flexibility when deploying the application in different environments (for example, development, staging, production).

For this tutorial, we have set the port number to 3000.

// Define the port number for the server to listen on
const port = 3000;

Now, let's set up the server-side part with Node.js and Express to handle SSE requests. We define a route (/sse) that will send a continuous stream of events to the client.

// Define a route that handles requests to /sse endpoint
app.get('/sse', (req, res) => {
//....
});

For the server to communicate with the client using SSE, we need to set specific HTTP headers:

• Content-Type: We specify 'text/event-stream' to let the client know that the response is an SSE stream.

• Cache-Control: Setting it to 'no-cache' ensures the client gets fresh data each time, without caching.

• Connection: This is set to 'keep-alive' to maintain the connection open for continuous data transmission.

app.get('/sse', (req, res) => {
  // Set the Content-Type header to 'text/event-stream' to indicate that 
  // the response will be an SSE stream
  res.setHeader('Content-Type', 'text/event-stream');

  // Prevent caching of the stream (important to ensure real-time updates)
  res.setHeader('Cache-Control', 'no-cache');

  // Keep the connection alive to continuously send events
  res.setHeader('Connection', 'keep-alive');
});

You can use res.flushHeaders() to send the headers immediately. Thus, the client can begin listening for events without delay.

To add a bit of flair, let's send a new SSE message every second, including the number of the message being sent. For this, we will initialize a variable counter , as well as to use setInterval to send a new message every second (1000ms).

app.get('/sse', (req, res) => {
  // Set the Content-Type header to 'text/event-stream' to indicate that 
  // the response will be an SSE stream
  res.setHeader('Content-Type', 'text/event-stream');

  // Prevent caching of the stream (important to ensure real-time updates)
  res.setHeader('Cache-Control', 'no-cache');

  // Keep the connection alive to continuously send events
  res.setHeader('Connection', 'keep-alive');

  // Send the headers immediately, so the client starts listening for events
  res.flushHeaders();

  // Initialize a counter variable for the messages
  let counter = 0;

  // Use setInterval to send a new message every second (1000ms)
  setInterval(() => {
    // Send a new SSE message, incrementing the counter each time
    // Each message is prefixed with 'data: ' and followed by the message content
    res.write(`data: This is message ${counter++}\n\n`);
  }, 1000); // This interval runs every 1000 milliseconds (1 second)
});

The last step is to start the Express server the following way:

app.listen(port, () => {
  console.log(`Server running at http://localhost:${port}`);
});

And that’s it! Make sure your server-sent code looks like this:

// Import the Express module
const express = require('express');
// Create an instance of the Express application
const app = express();

// Define the port number for the server to listen on
const port = 3000;

// Define a route that handles requests to /sse endpoint
app.get('/sse', (req, res) => {
  // Set the Content-Type header to 'text/event-stream' to indicate that 
  // the response will be an SSE stream
  res.setHeader('Content-Type', 'text/event-stream');

  // Prevent caching of the stream (important to ensure real-time updates)
  res.setHeader('Cache-Control', 'no-cache');

  // Keep the connection alive to continuously send events
  res.setHeader('Connection', 'keep-alive');

  // Send the headers immediately, so the client starts listening for events
  res.flushHeaders();

  // Initialize a counter variable for the messages
  let counter = 0;

  // Use setInterval to send a new message every second (1000ms)
  setInterval(() => {
    // Send a new SSE message, incrementing the counter each time
    // Each message is prefixed with 'data: ' and followed by the message content
    res.write(`data: This is message ${counter++}\n\n`);
  }, 1000); // This interval runs every 1000 milliseconds (1 second)
});

// Start the Express server and listen on the specified port
app.listen(port, () => {
  console.log(`Server running at http://localhost:${port}`);
});

WebSockets vs Server-Sent Events

The goal of data transfer methods is to load and display large datasets as quickly as possible. This ensures that the user perceives the response as instant and provides smooth navigation and a pleasant user experience.

Jakob Nielsen, a retired principal and co-founder of the Nielsen Norman Group, outlined three key time limits that developers should consider when optimizing web and application performance in his book Usability Engineering. In short, 0.1 seconds is the threshold for users to feel that the system is responding instantaneously, meaning that no special feedback is required other than simply displaying the result.

Vera Didenko, Software Architect and Developer at Flexmonster conducted research to identify the most efficient data transfer protocol and, based on the 100-millisecond constraint, calculated the time budget for each process, ultimately choosing WebSockets as the optimal method for loading and updating the data.

For research purposes, Vera created an application using .NET Core and SignalR to test and visually compare the performance of WebSockets and Server-Sent Events to discover which data transfer approach is the most performance-efficient. SignalR is an open-source library that simplifies real-time web functionality.

After running several tests for all methods simultaneously while increasing the number of calls each time, the test results were gathered in JSON format and fed to the amCharts library. Below are the test results for 100, 1000, and 10000 calls:

The experiment results show that WebSockets perform best for this task, emerging as the most performance-efficient data transfer technology in the simulated scenarios.

Which is Better: Server-Sent Events or WebSockets?

SSE is a simpler solution, but it isn't extensible: if your web application requirements were to change, it would likely need to be refactored using WebSockets. Also, with AI integration SSE becomes even more powerful and secure.

Although WebSocket technology presents more upfront work, it's a more versatile and extensible framework, so it’s a better option for complex applications that are likely to add new features over time.

In practice, many developers prefer WebSockets even for scenarios requiring receiving information rather than opting for SSE. This preference is not solely due to the limitations of SSE—such as its reliance on keeping a connection open for continuous data flow—but also because WebSockets offer greater versatility and are often considered more future-proof.

For instance, popular platforms like Reddit and Trello choose WebSockets to receive data (Reddit and Trello only send information to users when they are offered to subscribe to another person).

From personal experience, I can point out that SSE data often doesn’t appear in the developer tools, making it harder to debug and inspect. You can verify this by checking a web application like ChatGPT, where no SSE data sent by the server is visible in the developer tools network tab. This lack of transparency can make working with SSE more challenging than the more straightforward, visible data flow provided by WebSockets.

Wrapping Up

I hope this article was both interesting and useful to you! If you want to further strengthen your knowledge and take your skills to the next level, I highly recommend diving into real-life projects.

Personally, I found these on freeCodeCamp to be really useful and even a bit challenging: How to Build a Logging Web App with Server-Sent Events, RxJS, and Express and Learn WebSockets with Socket.IO. Not only will these projects give you hands-on experience, but they will also provide you with valuable new insights and skills that you can apply to future development challenges.

Happy coding, and keep learning!

By the end, you'll have a fully functional game with real-time capabilities and a solid understanding of how to use WebSockets and Redis to build scalable real-time applications.

What You Will Learn

• How to use Socket.IO for real-time communication.

• How to use Redis Pub/Sub to synchronize game state across multiple clients.

• How to set up a scalable WebSocket server architecture.

Prerequisites

Before we start, make sure you have the following installed:

• Node.js (v16 or higher)

• Redis

• Docker (optional, for running Redis in a container)

• Basic knowledge of JavaScript, Node.js, and WebSockets.

Table of Contents

• Project Overview

• Step 1: Setting Up Your Development Environment

• Step 2: Setting Up the Project

• Step 3: Implementing the WebSocket Server with Redis

• Step 4: Implement the React Frontend interface

• Step 5: Running the Application

• Step 6: Viewing Redis Messages in Real-Time

• Demo

• Conclusion

Project Overview

We'll build a real-time Tic-Tac-Toe game with the following features:

• Two players can connect and play a game.

• The game board updates in real-time across different browser tabs.

• The game announces a winner or declares a draw when the board is full.

We’ll use:

• Node.js with Socket.IO for handling WebSocket connections.

• Redis Pub/Sub to manage game state synchronization across clients.

Step 1: Setting Up Your Development Environment

Installing Node.js

Ensure you have Node.js installed on your system:

node -v

If you don’t have it installed, download it from Node.js.

Installing Redis

You can install Redis locally or run it in a Docker container.

macOS (Using Homebrew)

First, ensure that you have Homebrew installed on your system before running the commands below:

brew install redis
brew services start redis

Verify that the Redis container is running with the following command:

redis-cli ping

You should see:

PONG

Using Docker to Run Redis

docker run --name redis-server -p 6379:6379 -d redis

Check if Redis is running using:

docker exec -it redis-server redis-cli ping

Step 2: Setting Up the Project

1. Create the Project Directory

mkdir tic-tac-toe
cd tic-tac-toe
npm init -y

2. Install Dependencies

npm install express socket.io redis dotenv

3. Create Environment Variables

Create a .env file in your project root with the following contents:

PORT=3000
REDIS_HOST=localhost
REDIS_PORT=6379

Step 3: Implementing the WebSocket Server with Redis

In this step, we'll set up a WebSocket server that handles real-time game interactions using Node.js, Socket.IO, and Redis. This server will manage the game state, handle player moves, and ensure synchronization across multiple clients using Redis Pub/Sub.

We'll break down each section of the code so you understand exactly how everything fits together.Server Code Explanation

Create a file named server.js and add the following code:

import dotenv from 'dotenv';
import express from 'express';
import http from 'http';
import { Server } from 'socket.io';
import { createClient } from 'redis';

dotenv.config(); // Load environment variables from .env file

const app = express();
const server = http.createServer(app);
const io = new Server(server, {
  cors: {
    origin: "http://localhost:5173",
    methods: ["GET", "POST"],
  }
});

• dotenv: Loads environment variables from a .env file to keep sensitive information like ports and keys secure.

• express: Sets up a basic Express server to handle HTTP requests.

• http: We create an HTTP server using Node's built-in http module, which we'll use with Socket.IO for WebSocket communication.

• Socket.IO: This library enables real-time, bidirectional communication between the server and clients.

• CORS Configuration: Allows cross-origin requests from our frontend running on localhost:5173.

Then, to create Redis publisher and subscriber clients, we’ll add the following code to server.js:

// Initialize Redis clients
const pubClient = createClient();
const subClient = createClient();
await pubClient.connect();
await subClient.connect();

We use Redis to handle real-time data synchronization between connected clients.

• pubClient: Used to publish messages (like game state updates).

• subClient: Subscribes to messages (listens for updates).

• connect(): Establishes a connection to the Redis server.

In this paradigm, one client is used to publish updates, and the other one subscribes to updates. This helps avoid blocking behavior, since Redis clients in subscribe mode can only receive messages.

To subscribe to Redis channels for game updates, we’ll add the following code to server.js:

// Subscribe to the Redis channel for game updates
await subClient.subscribe('game-moves', (message) => {
  gameState = JSON.parse(message);
  io.emit('gameState', gameState);
});

• subClient.subscribe: Listens for messages on the game-moves channel.

• Whenever a new move is made by a player, the game state is updated in Redis, and all connected clients are informed of the new state.

• The message parameter contains the game state as a string. We parse it into a JavaScript object and broadcast the updated state using Socket.IO.

Next, to define the game state and functions, we’ll add the following code to server.js:

// Define initial game state
let gameState = {
  board: Array(9).fill(null),
  xIsNext: true,
};

// Function to reset the game
function resetGame() {
  gameState = {
    board: Array(9).fill(null),
    xIsNext: true,
  };
}

• gameState: Keeps track of the current state of the board and whose turn it is (xIsNext).

  • The board is represented as an array of 9 cells (each can be 'X', 'O', or null).

  • The xIsNext flag determines which player's turn it is.

• resetGame(): Resets the board and turn indicator to their initial state, allowing for a new game to start.

Next, to handle WebSocket connections, let’s add the following code to server.js:

io.on('connection', (socket) => {
  console.log('New client connected:', socket.id);

  // Send the current game state to the newly connected client
  socket.emit('gameState', gameState);

• The io.on('connection') event is triggered when a new client connects.

• socket.id: A unique identifier for each connected client.

• We immediately send the current gameState to the new client so they can see the current board.

To handle player moves, we’ll add the following code to server.js:

  // Handle player moves
  socket.on('makeMove', (index) => {
    // Prevent making a move if cell is already taken or game is over
    if (gameState.board[index] || calculateWinner(gameState.board)) return;

    // Update the board and switch turns
    gameState.board[index] = gameState.xIsNext ? 'X' : 'O';
    gameState.xIsNext = !gameState.xIsNext;

    // Publish the updated game state to Redis
    pubClient.publish('game-moves', JSON.stringify(gameState));
    io.emit('gameState', gameState);
  });

• makeMove: This event is triggered when a player clicks on a cell.

  • Validation: We check if the cell is already occupied or if the game has ended before making a move.

  • Updating Game State: If the move is valid, we update the board and switch turns.

• The updated game state is then:

  1. Published to Redis: This ensures that all instances of the server stay in sync.

  2. Broadcasted to all clients: This immediately updates the game board for all players.

To handle game restarts, we’ll add the following code to server.js:

// Handle game restarts
socket.on('restartGame', () => {
  resetGame();
  io.emit('gameState', gameState);
});

To handle client disconnection handling, we’ll add the following code to server.js:

 socket.on('disconnect', () => {
    console.log('Client disconnected:', socket.id);
  });
});

Finally, to process the logic of the game, we’ll add the following functions to server.js:

// Function to check if there's a winner
function calculateWinner(board) {
  const lines = [
    [0, 1, 2], [3, 4, 5], [6, 7, 8],
    [0, 3, 6], [1, 4, 7], [2, 5, 8],
    [0, 4, 8], [2, 4, 6]
  ];
  for (let [a, b, c] of lines) {
    if (board[a] && board[a] === board[b] && board[a] === board[c]) {
      return board[a];
    }
  }
  return null;
}

function isBoardFull(board) {
  return board.every((cell) => cell !== null);
}

• calculateWinner(): Checks if there’s a winning combination on the board.

• isBoardFull(): Checks if all cells are filled, indicating a draw.

Step 4: Implement the React Frontend interface

In this step, we build a simple and interactive React frontend for our Tic-Tac-Toe game. This frontend allows players to connect to the WebSocket server, make moves, and see the game board update in real-time.

In App.jsx, add the following code:

import React, { useEffect, useState } from 'react';
import io from 'socket.io-client';

const socket = io('http://localhost:3000');

function App() {
  const [gameState, setGameState] = useState({
    board: Array(9).fill(null),
    xIsNext: true,
    winner: null
  });

  useEffect(() => {
    socket.on('gameState', (state) => {
      setGameState(state);
    });

    return () => socket.off('gameState');
  }, []);

  const handleClick = (index) => {
    if (gameState.board[index] || gameState.winner) return;
    socket.emit('makeMove', index);
  };

  const renderCell = (index) => (
    <button onClick={() => handleClick(index)}>{gameState.board[index]}</button>
  );

  return (
    <div>
      <h1>Multiplayer Tic-Tac-Toe</h1>
      <div className="board">
        {[...Array(9)].map((_, i) => renderCell(i))}
      </div>
      <button onClick={() => socket.emit('restartGame')}>Restart Game</button>
    </div>
  );
}

export default App;

Here is a summary of how the React app is broken down:

• WebSocket Connection:

  • The frontend establishes a connection to the server using socket.io-client.

• State Management:

  • The game state (gameState) is managed with React's useState and includes:

    • The board (9 cells).

    • The flag xIsNext to indicate the current player's turn.

    • The winner status.

• Real-Time Updates:

  • The useEffect hook:

    • Listens for gameState updates from the server.

    • Updates the local game state when changes are detected.

    • Cleans up the WebSocket listener when the component is unmounted.

• Handling Player Moves:

  • The handleClick function:

    • Checks if a cell is already occupied or if the game has a winner before allowing a move.

    • Sends a makeMove event to the server with the clicked cell index.

• Game Board Rendering:

  • The renderCell function creates a button for each cell on the board.

  • The board is displayed using a 3x3 grid.

• Restart Game:

  • The "Restart Game" button emits a restartGame event to reset the game board for all players.

• User Interface:

  • A simple and interactive layout that allows players to take turns and see updates in real-time.

Step 5: Running the Application

Starting the Backend

To start the backend server, open a new terminal window and run the following commands:

cd tic-tac-toe
npm start

Starting the Frontend

To start the React frontend server, open a new terminal window and run the commands below (do not use the same one which the backend server is running on, as you need both running simultaneously to run the game).

cd tic-tac-toe-client
npm run dev

Accessing the Game

Open your browser and navigate to:

http://localhost:5173

Step 6: Viewing Redis Messages in Real-Time

While the game is running, you can view Redis messages to see real-time game state updates.

Open a terminal and run:

redis-cli
SUBSCRIBE game-moves

This will display game updates:

1) "message"
2) "game-moves"
3) "{\"board\":[\"X\",null,\"O\",null,\"X\",null,null,null,null],\"xIsNext\":false}"

Every time a move is made or the game state changes, the server publishes the updated game state to the game-moves channel. Using redis-cli, you can monitor these updates in real-time, as the game is being played.

Demo

In this demo, you'll see the Tic Tac Toe game running locally, demonstrating real-time updates as players take turns.

The gameplay showcases features such as turn switching, board updates, and game state announcements (winner or draw). This highlights how the game leverages WebSocket communication to provide a smooth, interactive experience.

Conclusion

Congratulations, you’ve successfully built a real-time multiplayer Tic-Tac-Toe game using Node.js, Socket.IO, and Redis. Here’s what you’ve learned:

• Real-time WebSocket communication using Socket.IO.

• Game state management using Redis Pub/Sub.

• Building a responsive front-end with React.

Next Steps

• Add player authentication.

• Implement a chat feature.

• Deploy your application to a cloud provider for scalability.

Happy coding!

In this article, we'll explore how to implement SSE in Go, discussing its benefits, use cases, and providing practical examples. By the end, you should know the basics of building real-time applications with efficient, unidirectional communication.

What are Server-Sent Events?

SSE is a web technology that allows servers to push data to clients over a single HTTP connection.

Unlike WebSockets, SSE is unidirectional, making it simpler to implement and ideal for scenarios where real-time updates from the server are required, but client-to-server communication is not necessary.

Developing a web application that uses SSE is straightforward. You'll need a bit of code on the server to stream events to the front-end, but the client side code works almost identically to websockets when it comes to handling incoming events. This is a one-way connection, so you can't send events from a client to a server.

Benefits of SSE

1. Simplicity: SSE is easier to implement compared to WebSockets.

2. Native browser support: Most modern browsers support SSE out of the box.

3. Automatic reconnection: Clients automatically attempt to reconnect if the connection is lost.

4. Efficient: Uses a single HTTP connection, reducing overhead.

How to Implement SSE in Go

For our example here, we'll create a simple SSE server in Go which just sends the data to the client every second with a current timestamp. The client can then connect to our server on port 8080 and receive these messages.

A real example could be something more sophisticated like sending notifications, displaying progress bar updates, and so on.

package main

import (
    "fmt"
    "net/http"
    "time"
)

func sseHandler(w http.ResponseWriter, r *http.Request) {
    // Set http headers required for SSE
    w.Header().Set("Content-Type", "text/event-stream")
    w.Header().Set("Cache-Control", "no-cache")
    w.Header().Set("Connection", "keep-alive")

    // You may need this locally for CORS requests
    w.Header().Set("Access-Control-Allow-Origin", "*")

    // Create a channel for client disconnection
    clientGone := r.Context().Done()

    rc := http.NewResponseController(w)
    t := time.NewTicker(time.Second)
    defer t.Stop()
    for {
        select {
        case <-clientGone:
            fmt.Println("Client disconnected")
            return
        case <-t.C:
            // Send an event to the client
            // Here we send only the "data" field, but there are few others
            _, err := fmt.Fprintf(w, "data: The time is %s\n\n", time.Now().Format(time.UnixDate))
            if err != nil {
                return
            }
            err = rc.Flush()
            if err != nil {
                return
            }
        }
    }
}

func main() {
    http.HandleFunc("/events", sseHandler)
    fmt.Println("server is running on :8080")
    if err := http.ListenAndServe(":8080", nil); err != nil {
        fmt.Println(err.Error())
    }
}

Key Components of the SSE Implementation

The event stream is a simple stream of text data which must be encoded using UTF-8. Messages in the event stream are separated by a pair of newline characters – \n\n. A colon as the first character of a line is in essence a comment, and is ignored.

In our server it is done here:

rc := http.NewResponseController(w)
fmt.Fprintf(w, "data: The time is %s\n\n", time.Now().Format(time.UnixDate))
// To make sure that the data is sent immediately
rc.Flush()

The server that sends events needs to respond using the MIME type text/event-stream. We do it by setting the response header here:

w.Header().Set("Content-Type", "text/event-stream")

You may have noticed that we set few other headers as well. One is to keep the HTTP connection open, and another to bypass CORS:

w.Header().Set("Cache-Control", "no-cache")
w.Header().Set("Connection", "keep-alive")
w.Header().Set("Access-Control-Allow-Origin", "*")

And the last important piece is to detect the disconnect. In Go, we'll receive it as a message in a specified channel:

clientGone := r.Context().Done()

for {
    select {
    case <-clientGone:
        fmt.Println("Client disconnected")
        return
    }
}

Each message received has some combination of the following fields, one per line. In our server we send only the data field which is enough, as other fields are optional. More details here.

• event – a string identifying the type of event described.

• data – the data field for the message.

• id – the event ID to set the EventSource object's last event ID value.

• retry – the reconnection time.

How to Receive the Events on the Client Side

On the front end or client side, you will have to use the EventSource interface. It's a browser API encapsulating Server-Sent Events. In the following example, our browser application receives the events from the server and prints them in a list.

<!doctype html>
<html>
    <body>
        <ul id="list"></ul>
    </body>

    <script type="text/javascript">
        const eventSrc = new EventSource("http://127.0.0.1:8080/events");

        const list = document.getElementById("list");

        eventSrc.onmessage = (event) => {
            const li = document.createElement("li");
            li.textContent = `message: ${event.data}`;

            list.appendChild(li);
        };
    </script>
</html>

Here is how it may look in your browser:

Best Practices for SSE in Golang

Event Formatting

In a real world project, a simple string of data may not be enough. In these cases, using a structured format like JSON can be a good option to send multiple data fields once. Here's an example:

{
  "status": "in_progress",
  "completion": 51.22
}

Reconnection Strategy and Error Handling

Something could always go wrong on both sides: the server might reject the connection for some reason or a client might abruptly disconnect.

In each case, you'll need to implement a backoff strategy for graceful reconnections. It's better to miss one message than completely break the event loop.

In JavaScript, you can check for errors in EventSource and then act accordingly:

eventSrc.onerror = (err) => {
  console.error("EventSource failed:", err);
};

Load Balancing

For high-traffic applications, you may consider using a Load Balancer, for example NGINX. If you plan to have many clients connecting to your server, it's good to test it beforehand by simulating the load from the clients.

Use Cases for SSE

1. Real-time dashboards

2. Live sports scores

3. Social media feeds

4. Stock market tickers

5. Progress indicators for long-running tasks

Conclusion

Server-Sent Events provide an efficient and straightforward way to implement real-time, server-to-client communication in Golang applications. By leveraging SSE, developers can create responsive and dynamic web applications with minimal overhead and complexity.

As you build your SSE-powered applications, remember to consider scalability, error handling, and client-side implementation to ensure a robust and efficient real-time communication system.

Explore more articles from packagemain.tech