Realtime Communication in Web Applications

Modern web applications increasingly demand realtime communication capabilities to deliver dynamic, responsive user experiences. Whether it’s live chat, collaborative editing, realtime notifications, or streaming video, implementing realtime features is essential for engaging users. In this chapter, we’ll explore the engineering considerations behind setting up and using realtime communication on the web. We’ll delve into the specifics of WebSockets, Server-Sent Events (SSE), the publish-subscribe (pub/sub) pattern, WebRTC, and streaming video, providing practical guidance and code examples to help you integrate these technologies into your applications.

What is “Realtime Communication”?

Most of our typical web communication is based on the request-response model. The client sends a request to the server, which processes it and sends back a response. This model works well for many applications, but it has limitations when it comes to delivering dynamic, interactive experiences.

Realtime communication refers to the instantaneous exchange of data between a client and a server or between peers. Unlike traditional request-response models where the client initiates all interactions, realtime communication allows servers to push updates to clients as soon as they occur, enabling features like live updates and interactive collaboration. It also allows clients and servers to send data to each other without waiting for a response or encapsulating the entire message within an HTTP request/response - which still needs to be done even for H2 and H3, even though the framing layer minimizes the overhead of the request/response cycle.

Key challenges in realtime communication include managing persistent connections, ensuring low latency, handling scalability for numerous concurrent users, and optimizing resource usage.

Engineering Approaches to Real-Time Communication

Several methods exist to implement realtime communication in the browser, each with its own trade-offs:

Polling: Clients periodically send requests to the server to check for updates.
Long Polling: Clients send a request that the server holds open until an update is available.
Server-Sent Events (SSE): The server can push updates to the client over a single, long-lived HTTP connection.
WebSockets: A protocol providing full-duplex communication channels over a single TCP connection.
WebRTC: A set of APIs and protocols enabling realtime peer-to-peer communication of audio, video, and data.

We’ll focus on WebSockets, SSE, pub/sub patterns, and WebRTC, as they offer efficient and scalable solutions for realtime communication needs.

WebSockets: Enabling Full-Duplex Communication

How WebSockets Work

WebSockets provide a persistent, full-duplex communication channel between the client and server over a single TCP connection. This allows both parties to send data at any time without the overhead of establishing new connections for each message.

The WebSocket protocol starts with an HTTP handshake to establish the connection. Once the handshake is complete, the protocol is upgraded to WebSocket, which enables efficient two-way communication. This upgrade significantly reduces latency compared to traditional polling methods because it avoids the need to repeatedly establish new connections.

Practical Considerations

Establishing a WebSocket Connection

To set up a WebSocket connection, you initiate it from the client using JavaScript:

const socket = new WebSocket('ws://example.com/socketserver');

On the server side, you need a WebSocket server to handle incoming connections. Here’s a simple example using Node.js and the ws library:

const WebSocket = require('ws');
const server = new WebSocket.Server({ port: 8080 });

server.on('connection', socket => {
  console.log('Client connected');
  socket.on('message', message => {
    console.log(`Received: ${message}`);
    // Echo the message back to the client
    socket.send(`Server says: ${message}`);
  });

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

Upgrading from HTTP to WebSocket (WS)

The WebSocket protocol begins by establishing a connection using a regular HTTP request, known as the HTTP handshake. During this handshake, the client sends an Upgrade header to the server, indicating its intent to switch protocols to WebSocket. The server, if capable, responds with a 101 Switching Protocols status code, signaling that the connection is being upgraded from HTTP to WS.

Server Handling the Upgrade

The server must support the WebSocket protocol to successfully handle the upgrade. Here is an example using Node.js and the ws library to handle the upgrade process:

const http = require('http');
const WebSocket = require('ws');

const server = http.createServer();
const wss = new WebSocket.Server({ noServer: true });

server.on('upgrade', (request, socket, head) => {
  wss.handleUpgrade(request, socket, head, (ws) => {
    wss.emit('connection', ws, request);
  });
});

wss.on('connection', (socket) => {
  console.log('Client connected via WebSocket');
  socket.on('message', (message) => {
    console.log(`Received: ${message}`);
    socket.send(`Server says: ${message}`);
  });
});

server.listen(8080, () => {
  console.log('Server is listening on port 8080');
});

In this example, the HTTP server listens for upgrade events, which indicate that a client is requesting an upgrade to WebSocket. The wss.handleUpgrade() method takes care of switching the connection from HTTP to WebSocket, allowing the server to start communicating in full-duplex mode.

Handling Disconnections and Reconnections

Persistent connections can be interrupted due to network issues or server restarts. Implementing reconnection logic on the client side ensures a resilient connection:

function connect() {
  const socket = new WebSocket('ws://example.com/socketserver');

  socket.onopen = () => {
    console.log('WebSocket connection established');
  };

  socket.onclose = event => {
    console.log(`WebSocket closed: ${event.reason}`);
    // Attempt to reconnect after a delay
    setTimeout(connect, 1000);
  };

  socket.onerror = error => {
    console.error(`WebSocket error: ${error.message}`);
    socket.close();
  };

  socket.onmessage = event => {
    console.log(`Received: ${event.data}`);
  };
}

connect();

Optimizing Data Flow

For high-frequency events, it’s important to optimize data flow to prevent overwhelming the client or network:

Throttling: Limit the rate at which messages are sent by restricting the frequency of outgoing messages. This can be achieved using tools like setTimeout or rate-limiting libraries to control how often messages are dispatched. Throttling ensures that clients are not overwhelmed by a flood of data, which can lead to degraded performance or missed updates.
Batching: Combine multiple messages into a single payload before sending them. For instance, if multiple updates are generated in a short time frame, you can collect these updates and send them together in a single message. This reduces the number of network requests and helps in minimizing overhead, making communication more efficient. This approach can also use setInterval - for instance, rather than sending messages directly when an event happens, the application can append to a pendingMessage queue, and then the interval event handler can send all messages at once, causing only one function invocation for both the sending client and the receiver.
Compression: Enable per-message compression to reduce the size of messages being transmitted. This can be done using compression algorithms like Gzip or Brotli to minimize the amount of data sent over the network, which helps in reducing bandwidth usage and speeding up the communication process. Compression is particularly useful for larger messages or when communicating over bandwidth-constrained networks. You can also consider using a higher performance serialization algorithm like protobuf.

Scaling WebSocket Connections

Challenges

Concurrency: Handling a large number of simultaneous connections can strain server resources, especially when each connection requires its own thread or dedicated resources. For example, an online multiplayer game server handling thousands of players simultaneously needs efficient resource management to maintain low latency.
State Management: Maintaining connection state across distributed systems requires careful design. When connections are spread across multiple servers, ensuring each server has access to the correct client state becomes challenging. For example, in a real-time collaborative editing application, the state must be synchronized so that all users see consistent updates, even if their connections are managed by different servers.
Load Balancing: Traditional load balancers may not be suitable for WebSocket traffic because they are typically designed for stateless HTTP requests. WebSocket connections are long-lived, requiring load balancers to maintain sticky sessions to ensure all messages from a client go to the same server instance. For example, a live chat application must ensure that users stay connected to the same server to maintain their conversation context.

Strategies

Sticky Sessions: Configure the load balancer to route all messages from a client to the same server instance. This can be achieved by using cookies or IP hash to ensure that clients maintain their session with a specific server. For instance, in a stock trading platform, sticky sessions ensure that user data, such as ongoing trades, remains consistent by always routing requests to the same server.
Horizontal Scaling: Deploy multiple server instances and distribute connections among them. Horizontal scaling helps handle increased load by adding more servers to share the connections. For example, a gaming server might scale horizontally during peak hours to handle increased player activity. Load balancers play a crucial role here to distribute incoming WebSocket connection requests across all available instances.
Message Brokers: Use systems like Redis or Kafka to handle pub/sub messaging between servers. This approach decouples the WebSocket connections from the actual data processing, enabling efficient communication between distributed server nodes. For example, in a notification system, Redis can be used to publish a message that needs to be sent to multiple subscribers across different server instances, ensuring all connected clients receive the update promptly.

Scalable performance for live updates over websockets is one of the situations in which it’s worth considering switching to a different language, like Go or Elixir, which were designed from the ground up to effectively handle large numbers of concurrent connections. While these systems are typically not directly connected to web development---many of them will not interact with the web code at all, either on the front end or the backend, but instead simply connect to a message broker---it’s still important to understand the challenges involved in deploying scalable realtime systems.

Example Application with WebSockets

Let’s build a simple demo for WebSockets using Hono. The client in this instance will periodically send a string to the server, and the server will just print it to the screen.

Server-Side Code (Node.js with `hono` and `node-ws`)

import { createNodeWebSocket } from '@hono/node-ws'
import { Hono } from 'hono'
import { serve } from '@hono/node-server'

const app = new Hono()

const { injectWebSocket, upgradeWebSocket } = createNodeWebSocket({ app })

app.get('/ws', upgradeWebSocket((c) => ({
    return {
      onMessage(event, ws) {
        console.log(`Message from client: ${event.data}`)
        ws.send('Hello from server!')
      },
      onClose: () => {
        console.log('Connection closed')
      },
    }
})))

const server = serve(app)
injectWebSocket(server)

Client-Side Code

import { hc } from 'hono/client'
import type app from './server'

const client = hc<typeof app>('http://localhost:8787')
const ws = client.ws.$ws(0)

ws.addEventListener('open', () => {
  setInterval(() => {
    ws.send(new Date().toString())
  }, 1000)
})

Server-Sent Events (SSE): Efficient Unidirectional Updates

How SSE Works

SSE allows the server to push updates to the client over a single, long-lived HTTP connection. It’s unidirectional—from server to client—which makes it ideal for scenarios where the client needs to receive continuous updates without sending data back. SSE is particularly useful for use cases such as live comment feeds on a news website or stock ticker updates.

Compared to WebSockets, SSE is simpler to implement when you only need server-to-client communication. Unlike WebSockets, there is no need to manage the complexities of a bidirectional protocol.

Practical Considerations

Establishing an SSE Connection

On the client side, you create an EventSource:

const eventSource = new EventSource('/events');

eventSource.onmessage = event => {
  console.log(`New message: ${event.data}`);
};

eventSource.onerror = error => {
  console.error('EventSource failed:', error);
};

On the server side, you need to set the appropriate headers and write data in the SSE format:

const http = require('http');

http.createServer((req, res) => {
  if (req.url === '/events') {
    res.writeHead(200, {
      'Content-Type': 'text/event-stream',
      'Cache-Control': 'no-cache',
      'Connection': 'keep-alive',
    });

    const interval = setInterval(() => {
      res.write(`data: ${new Date().toISOString()}

`);
    }, 1000);

    req.on('close', () => {
      clearInterval(interval);
    });
  }
}).listen(8000);

Earlier in class we talked about the Chunked encoding, that allows a server to send bits of information as part of a larger http request, that are then able to be processed chunk-by-chunk by the client side. That’s all that SSE’s are - with an API built around it that makes life a bit simpler. Browsers automatically attempt to reconnect when an SSE connection is lost. You can handle reconnection logic on the server if needed.

Example Use Case: Live News Feed

To implement a live news feed with SSE that allows clients to receive updates as they happen without polling, you can use the same structure as above for the server, and this code for the client:

const eventSource = new EventSource('/news');

eventSource.onmessage = event => {
  const newsItem = JSON.parse(event.data);
  displayNews(newsItem);
};

As your application scales and your user base grows, handling real-time communication efficiently becomes more challenging. This is where the pub/sub model can provide a significant advantage over using bare WebSockets. When you have multiple clients that need to receive the same updates (e.g., a live news feed or a shared workspace where many users need to be notified of changes), a simple one-to-one WebSocket connection model becomes cumbersome and difficult to scale. Pub/sub helps decouple message production from message consumption, allowing you to broadcast updates to many clients through channels, without each client having to maintain a direct connection to the publisher. This results in improved scalability, better resource management, and more organized communication flow.

Pub/Sub Fundamentals

The pub/sub pattern decouples message producers (publishers) from consumers (subscribers). Publishers emit messages to channels without knowledge of subscribers, who listen to channels of interest.

Engineering Pub/Sub with Real-Time Protocols

Implementing Pub/Sub with WebSockets

You can implement the pub/sub pattern over WebSockets directly by managing channels on the server. In this example, pub/sub is used to maintain a chat server with multiple channels, such that when new messages arrive, they’re only sent to the users that are subscribed to that channel.

const channels = {};

server.on('connection', socket => {
  socket.on('message', message => {
    const { command, channel, data } = JSON.parse(message);
    if (command === 'subscribe') {
      if (!channels[channel]) channels[channel] = new Set();
      channels[channel].add(socket);
    } else if (command === 'publish') {
      const subscribers = channels[channel];
      if (subscribers) {
        for (const subscriber of subscribers) {
          subscriber.send(JSON.stringify({ channel, data }));
        }
      }
    }
  });

  socket.on('close', () => {
    for (const subscribers of Object.values(channels)) {
      subscribers.delete(socket);
    }
  });
});

Using Message Brokers

Motivation: As your application grows, handling a high volume of real-time communication using direct WebSocket connections becomes increasingly challenging, especially when multiple clients need to receive the same updates. Using a message broker like Redis helps manage this complexity.

A message broker decouples message production from consumption, which increases performance by reducing the direct load on the publisher and distributing work more evenly. Instead of the publisher managing multiple WebSocket connections, a message broker handles the distribution of messages, allowing the publisher to focus on generating data. Redis, for example, uses efficient in-memory storage to handle large volumes of messages with minimal latency, ensuring all subscribers receive updates quickly and reliably. By using the message broker as a central mechanism to handle all publish-subscribe communication, individual clients can connect to simple replicas of the web server code that aren’t responsible for the entire process, but only handling that individual user’s messages. You could imagine in a system like discord, millions of users are potentially connected to thousands of channels - but the websocket connection for any individual user only needs to manage sending and receiving messages for that one user, rather than the entire system.

One popular application for managing pubsub is redis, the “data structure server” which allows a variety of operations to be run against individual keys in its key-value store. For instance, a key can hold a list, and thus running redisClient.lpop("keyname") will remove and return the leftmost element in the list stored at the key “keyname.” Another such operation is subscribe, which allows the client (which importantly in this example is the web server application - browsers cannot and should not directly connect to redis) to wait and listen for any messages that other clients send by running the publish operation on that same key.

Consider a live news application where breaking news needs to be broadcast to all users. Using Redis, you can publish news updates to a channel, and any client subscribed to that channel will receive the news instantly.

const redis = require('redis');
const subscriber = redis.createClient();

subscriber.subscribe('news');

subscriber.on('message', (channel, message) => {
  // Forward message to connected WebSocket clients
});

WebRTC: Peer-to-Peer Communication for Real-Time Audio, Video, and Data

WebRTC (Web Real-Time Communication) was created to enable direct peer-to-peer communication of audio, video, and data between browsers. The motivation behind WebRTC was to eliminate the need for plugins or external software to achieve real-time, low-latency communication, making it an open standard for any browser-based application to facilitate seamless communication. It was designed to be built directly into the browser, using JavaScript APIs, which makes integrating real-time features straightforward and more accessible to developers.

When to Use WebRTC

WebRTC is ideally suited for situations where low-latency, peer-to-peer media streaming is required. This makes it an excellent choice for applications like:

Video conferencing: WebRTC provides the ability to establish direct video and audio connections between users, reducing the need for centralized server-based processing.

File sharing: Since it supports data channels, WebRTC can be used to directly transfer files between users without the need for server intermediaries.

Real-time collaboration: WebRTC’s data channels allow for efficient sharing of data, enabling real-time collaboration tools like whiteboards or multiplayer games.

Advantages of WebRTC

Low Latency: By establishing direct connections between peers, WebRTC can achieve very low latency, which is crucial for real-time applications like voice and video calls.

No Plugins Required: WebRTC runs directly in the browser, eliminating the need for users to download third-party plugins or applications, which simplifies user onboarding and improves security.

Efficient Resource Use: WebRTC offloads the burden of routing audio and video data from the server, allowing for more efficient use of server resources since media is sent directly between peers.

Disadvantages of WebRTC

Complex Setup: Establishing a WebRTC connection requires signaling, NAT traversal, and handling various network configurations, which can make implementation complex. The signaling process itself is not defined by WebRTC, so developers need to implement a separate mechanism (e.g., using WebSockets).

Network Challenges: WebRTC relies on ICE (Interactive Connectivity Establishment) to find the best path between peers, which can be challenging when dealing with NATs (Network Address Translators) and firewalls. In certain cases, TURN servers are needed to relay data, which can introduce additional latency and costs.

Scalability Limitations: Since WebRTC is primarily peer-to-peer, it can struggle to scale for larger group calls. For group video calls, Selective Forwarding Units (SFUs) or Multipoint Control Units (MCUs) are often required to relay or mix streams, which can add complexity and infrastructure requirements.

Summary of WebRTC

WebRTC is a powerful tool for enabling peer-to-peer communication directly between browsers, making it ideal for scenarios where minimizing latency is crucial. Its major strength is in its ability to establish direct connections without requiring centralized servers for media transfer. However, its complexity in setup and challenges with NAT traversal mean it may not always be the best fit, particularly for applications requiring massive scalability. In such cases, combining WebRTC with supporting infrastructure like signaling servers and TURN/SFU servers is often necessary to achieve reliable and efficient communication.

At the end of the day, as of this writing (late 2024) WebRTC only sees limited use in various scenarios. In many cases, the demand for direct peer-to-peer connections without a server just doesn’t create enough value compared to the features that a server can provide (more reliable reconnection, saving and buffering content), especially when combined with things like end-to-end encryption that minimize a lot of the privacy concerns related to sharing your content with a server. For instance, Zoom primarily uses their own technology via WebAssembly and don’t use WebRTC in their main application, and many “send this file” services default to saving the encrypted file on a server rather than sending it directly over WebRTC (although this is an option available on my own personal favorite, wormhole.app).

Video Streaming in Real-Time Applications

On a user-by-user, minute-by-minute basis, video streaming is probably the most important application on the entire web. Video streaming can be broadly classified into two types: live streaming and stored video streaming.

Live Streaming: This type of streaming involves broadcasting content as it is happening in real-time. Platforms like Twitch are prime examples, where users can watch events live, such as gaming sessions or live shows. Live streaming aims to minimize latency to provide viewers with as close to real-time experience as possible.
Stored Video Streaming: Stored, or on-demand, video streaming involves content that has been pre-recorded and saved for future consumption. YouTube is a prime example of stored video streaming, where users can access video content at any time, play, pause, or rewind, giving them more control over their viewing experience.

Challenges in Video Streaming

Challenges in Live Streaming

Low Latency: Live streaming requires maintaining low latency to ensure viewers experience the event almost as it happens. Managing latency can be challenging as any delays in processing, encoding, or transmitting the content can lead to buffering or a delayed stream.
Bandwidth Management: Live streaming demands a continuous and consistent bandwidth supply. Variations in network speed can impact stream quality, leading to buffering issues.
Scalability: Handling spikes in viewers is another significant challenge. A live broadcast may suddenly experience a surge in viewers, requiring the infrastructure to scale dynamically to manage the load.

Challenges in Stored Video Streaming

Efficient Storage: Stored video streaming involves storing large amounts of video content, which requires efficient data storage solutions. Handling the sheer volume of video files while maintaining fast access speeds is a major challenge.
Adaptive Bitrate Streaming: Stored video must accommodate different network conditions for users. Implementing adaptive bitrate streaming ensures that users with slower internet connections can still enjoy the content at lower quality, while users with better connections receive higher quality streams.
Content Delivery: Delivering stored content efficiently to users spread across different geographic locations involves using a robust CDN (Content Delivery Network) to minimize buffering and load times.

High performance video codecs

One of the most important low-level considerations in a video streaming service is the type of lossy compression used to encode and decode a given video stream. The performance (in terms of speed, quality, and compression ratio) makes a huge difference in how users perceive the video, and how much it costs to store and transfer it. There has been quite a bit of development in this space in recent years, and here are a few of the codecs that you would probably choose between if you were deploying a streaming site in 2024:

1. **H.264 (Advanced Video Coding)**: H.264 is one of the most widely used video compression standards, known for its efficient compression while maintaining high video quality. It strikes a good balance between quality and file size, making it suitable for both live and on-demand streaming. H.264 is supported on nearly all devices and platforms, which makes it a default choice for compatibility.

2. **H.265 (High Efficiency Video Coding, HEVC)**: H.265 is the successor to H.264 and offers roughly double the compression efficiency, which means it provides the same quality at about half the bitrate. This makes H.265 an excellent choice for high-resolution content like 4K streaming. However, H.265 has limited browser support and higher computational requirements for encoding and decoding.

3. **VP9**: Developed by Google, VP9 is an open and royalty-free codec that offers compression efficiency similar to H.265. VP9 is widely supported in modern browsers, particularly in Google Chrome and YouTube, and is used heavily for streaming videos at different resolutions to save bandwidth. Unlike H.265, VP9 is royalty-free, making it more attractive for companies looking to avoid licensing fees.

4. **AV1**: AV1 is the newest codec, developed by the Alliance for Open Media. It offers even greater compression efficiency than H.265 and VP9, making it ideal for high-quality video streaming with minimal bandwidth use. AV1 is open-source and royalty-free, but due to its high computational complexity, it’s currently more challenging to encode in real time. However, AV1 is expected to become more prevalent as hardware support grows.

Each codec has its own strengths: H.264 for compatibility, H.265 for higher efficiency, VP9 for open usage without royalties, and AV1 for the future of efficient streaming at scale.

Overview of Video Streaming Protocols

RTMP (Real-Time Messaging Protocol): RTMP is a protocol designed for low-latency transmission of audio, video, and data between an encoder and a media server. Initially developed by Adobe, RTMP works by establishing a persistent connection that allows continuous data transfer, making it particularly useful for live streaming applications where minimizing delays is crucial. RTMP breaks down the video and audio streams into small packets, which are then transmitted over a TCP connection. The server can then process and repackage the stream for delivery to end users using other protocols like HLS or DASH. This approach makes RTMP effective for live broadcast scenarios, such as streaming events or live gaming.
DASH (Dynamic Adaptive Streaming over HTTP): DASH is an adaptive bitrate streaming protocol that provides a high-quality streaming experience for users by dynamically adjusting the video quality based on network conditions. Unlike HLS, DASH is an open standard and is not tied to any specific company, which makes it highly flexible and widely supported across various platforms and devices. DASH segments the video into small chunks and provides multiple quality levels, allowing the client to select the best quality depending on the current network conditions. Implementing DASH involves encoding video content into multiple quality levels, storing them as segments, and using a manifest file that guides the client on which segments to request. DASH is particularly useful in scenarios where cross-platform compatibility and support for various codecs are essential.
HLS (HTTP Live Streaming): HLS is a widely adopted protocol developed by Apple that is built into most browsers, making it easy to implement for both live and on-demand streaming. Its key advantage is adaptive bitrate streaming, which allows clients to automatically switch video quality based on their network conditions, providing a smooth viewing experience even with fluctuating bandwidth. Unlike DASH, which is also an adaptive bitrate streaming protocol but not natively supported by all browsers, HLS is often the preferred choice for broader compatibility. This means that developers can reach a larger audience without relying on additional plugins or tools, which simplifies deployment and reduces compatibility concerns.

Both DASH (Dynamic Adaptive Streaming over HTTP) and HLS (HTTP Live Streaming) handle bandwidth, buffering, and stream quality management automatically through adaptive bitrate streaming. This technology allows the client to request video segments of different quality levels depending on the current network conditions. If bandwidth decreases, the client automatically switches to a lower bitrate stream to reduce buffering, and if bandwidth increases, it switches to a higher quality. This automatic adjustment ensures the user gets the best possible quality without interruptions, making both protocols highly effective for providing a smooth streaming experience.

Choosing the Right Real-Time Communication Approach

Trade-offs and Practical Tips

WebSockets: Best for bidirectional communication where both client and server can send messages independently.
SSE: Ideal for server-to-client unidirectional streaming with simple implementation.
WebRTC: Suited for peer-to-peer audio, video, and data transfer with low latency.

Consider creating a table that summarizes the strengths and weaknesses of WebSockets, SSE, and WebRTC side-by-side for easy comparison:

Technology	Strengths	Weaknesses
WebSockets	Full-duplex communication, low latency	Complex scaling, requires bidirectional
SSE	Simple server-to-client, auto-reconnect	Unidirectional, limited browser support
WebRTC	Peer-to-peer, low latency for media	Complex setup, needs signaling server

Guidelines for Real-Time App Architecture

Use Established Libraries: Simplify implementation using libraries like Socket.IO, SignalR, or PeerJS.
Consider Protocol Overheads: Balance features against the overhead of implementing them.

Conclusion

Implementing realtime communication in web applications involves careful consideration of the available technologies and their trade-offs. Understanding the specifics of WebSockets, SSE, the pub/sub pattern, and WebRTC enables you to choose the right tools for your application’s needs. By focusing on engineering best practices, optimizing performance, and planning for scalability, you can create responsive and engaging realtime experiences for your users.

Realtime Communication in Web Applications

What is “Realtime Communication”?

Engineering Approaches to Real-Time Communication

WebSockets: Enabling Full-Duplex Communication

How WebSockets Work

Practical Considerations

Establishing a WebSocket Connection

Upgrading from HTTP to WebSocket (WS)

Server Handling the Upgrade

Handling Disconnections and Reconnections

Optimizing Data Flow

Scaling WebSocket Connections

Challenges

Strategies

Example Application with WebSockets

Server-Side Code (Node.js with hono and node-ws)

Client-Side Code

Server-Sent Events (SSE): Efficient Unidirectional Updates

How SSE Works

Practical Considerations

Establishing an SSE Connection

Example Use Case: Live News Feed

Publish-Subscribe (Pub/Sub) Model in Real-Time Communication

Pub/Sub Fundamentals

Engineering Pub/Sub with Real-Time Protocols

Implementing Pub/Sub with WebSockets

Using Message Brokers

WebRTC: Peer-to-Peer Communication for Real-Time Audio, Video, and Data

When to Use WebRTC

Advantages of WebRTC

Disadvantages of WebRTC

Summary of WebRTC

Video Streaming in Real-Time Applications

Challenges in Video Streaming

Challenges in Live Streaming

Challenges in Stored Video Streaming

High performance video codecs

Other Technologies Used in Video Streaming

Overview of Video Streaming Protocols

Choosing the Right Real-Time Communication Approach

Trade-offs and Practical Tips

Guidelines for Real-Time App Architecture

Conclusion

Server-Side Code (Node.js with `hono` and `node-ws`)