Broadcasting to multiple clients in FastAPI - Step-by-Step Execution

Concept Flow - Broadcasting to multiple clients

Client connects

↓

Add client to list

↓

Server receives message

↓

Broadcast message to all clients

↓

Each client receives message

↓

Client disconnects

↓

Remove client from list

Clients connect and are tracked by the server. When a message arrives, the server sends it to all connected clients. Clients receive messages until they disconnect.

Execution Sample

FastAPI

from fastapi import FastAPI, WebSocket
app = FastAPI()
clients = set()

@app.websocket('/ws')
async def websocket_endpoint(ws: WebSocket):
    await ws.accept()
    clients.add(ws)
    try:
        while True:
            data = await ws.receive_text()
            for client in list(clients):
                try:
                    await client.send_text(f'Message: {data}')
                except Exception:
                    clients.discard(client)
    except Exception:
        clients.discard(ws)

This code accepts WebSocket clients, adds them to a set, and broadcasts received messages to all connected clients.

Execution Table

Step	Action	Clients Set	Message Received	Broadcast Action	Client Receives
1	Client A connects	Clients = {A}	-	-	-
2	Client B connects	Clients = {A, B}	-	-	-
3	Client A sends 'Hello'	Clients = {A, B}	'Hello'	Send 'Message: Hello' to A and B	A and B receive 'Message: Hello'
4	Client B sends 'Hi'	Clients = {A, B}	'Hi'	Send 'Message: Hi' to A and B	A and B receive 'Message: Hi'
5	Client A disconnects	Clients = {B}	-	-	-
6	Client B sends 'Bye'	Clients = {B}	'Bye'	Send 'Message: Bye' to B	B receives 'Message: Bye'
7	Client B disconnects	Clients = {}	-	-	-

💡 All clients disconnected, clients set is empty, no more broadcasting.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 5	After Step 7
clients	{}	{A}	{A, B}	{A, B}	{B}	{}

Key Moments - 3 Insights

Why do we add clients to a set instead of a list?

Using a set avoids duplicate clients and allows fast removal, as shown in execution_table rows 1, 2, and 5 where clients are added and removed efficiently.

What happens if a client disconnects during broadcasting?

The client is removed from the clients set (see step 5 and 7), so future broadcasts exclude disconnected clients, preventing errors.

Why do we use a try-except block around the receive and broadcast loop?

To catch disconnection or errors and remove the client safely, as seen in steps 5 and 7 where clients are removed after exceptions.

Visual Quiz - 3 Questions

Look at the execution_table at step 3, which clients receive the message 'Hello'?

A Only Client B

B Both Client A and Client B

C Only Client A

D No clients receive it

💡 Hint

Check the 'Client Receives' column at step 3 in the execution_table.

At which step does Client A disconnect from the server?

A Step 2

B Step 6

C Step 5

D Step 7

💡 Hint

Look at the 'Action' and 'Clients Set' columns to see when Client A is removed.

If a new Client C connects after step 7, what will be the clients set?

A {C}

B {}

C {A, B, C}

D {B, C}

💡 Hint

Refer to variable_tracker and execution_table showing clients after all disconnect.

Concept Snapshot

Broadcasting to multiple clients in FastAPI:
- Use a set to track connected WebSocket clients.
- On client connect, add to set; on disconnect, remove.
- When a message is received, loop over clients and send the message.
- Use try-except to handle disconnects gracefully.
- This allows real-time message sharing to all connected clients.

Full Transcript

This visual execution trace shows how FastAPI handles broadcasting messages to multiple WebSocket clients. Clients connect and are added to a set. When a client sends a message, the server loops through all connected clients and sends the message to each. If a client disconnects, it is removed from the set to avoid errors. The try-except block ensures the server handles disconnections smoothly. The execution table tracks each step, showing client connections, messages received, and broadcasts sent. The variable tracker shows how the clients set changes over time. Key moments clarify why a set is used, how disconnections are handled, and the importance of error handling. The quiz tests understanding of client reception, disconnection timing, and client set updates. This approach enables real-time communication to many clients efficiently and safely.