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.

Practice

1. What is the main purpose of broadcasting in FastAPI WebSocket applications?

easy

A. To send the same message to multiple connected clients at once

B. To send a message to only one client at a time

C. To close all client connections simultaneously

D. To authenticate clients before connection

Solution

1. Step 1: Understand broadcasting concept

   Broadcasting means sending one message to many clients simultaneously.

2. Step 2: Compare options with broadcasting definition

   Only 'To send the same message to multiple connected clients at once' accurately describes broadcasting.

3. Final Answer:

   To send the same message to multiple connected clients at once -> Option A

4. Quick Check:

   Broadcasting = send to many clients [OK]

Hint: Broadcasting means sending one message to many clients [OK]

Common Mistakes:

• Confusing broadcasting with single client messaging
• Thinking broadcasting closes connections
• Mixing broadcasting with authentication

2. Which of the following is the correct way to send a message to all clients in a FastAPI WebSocket manager class?

easy

A. self.connections.send(message)

B. await self.connections.send_text(message)

C. for client in self.connections: client.send(message)

D. for client in self.connections: await client.send_text(message)

Solution

1. Step 1: Identify correct syntax for sending messages

   In FastAPI WebSocket, sending text requires await and send_text method on each client.

2. Step 2: Check each option for correct usage

   for client in self.connections: await client.send_text(message) loops through connections and awaits send_text, which is correct. Others miss await or use wrong methods.

3. Final Answer:

   for client in self.connections: await client.send_text(message) -> Option D

4. Quick Check:

   Use await and send_text per client [OK]

Hint: Use await and send_text inside a loop for all clients [OK]

Common Mistakes:

• Forgetting to await send_text
• Trying to send to all clients at once without loop
• Using send instead of send_text

3. Given this snippet inside a FastAPI WebSocket manager class:

async def broadcast(self, message: str):
    for connection in self.active_connections:
        await connection.send_text(message)

What happens if self.active_connections is empty when broadcast is called?

medium

A. An IndexError is raised

B. The server crashes with a runtime error

C. No messages are sent and no error occurs

D. The message is sent to a default client

Solution

1. Step 1: Understand for-loop behavior on empty list

   A for-loop over an empty list runs zero times and does nothing without error.

2. Step 2: Apply to broadcast method

   If active_connections is empty, the loop sends no messages but does not raise errors.

3. Final Answer:

   No messages are sent and no error occurs -> Option C

4. Quick Check:

   Empty list loop = no action, no error [OK]

Hint: Empty loops run zero times without errors [OK]

Common Mistakes:

• Assuming empty list causes errors
• Thinking a default client receives message
• Confusing IndexError with empty iteration

4. You have this code snippet in your FastAPI WebSocket manager:

async def broadcast(self, message: str):
    for connection in self.active_connections:
        connection.send_text(message)

Why does this code cause an error when broadcasting?

medium

A. Missing await before connection.send_text causes coroutine not awaited error

B. send_text is not a valid method on WebSocket connections

C. active_connections should be a dictionary, not a list

D. The for loop syntax is incorrect

Solution

1. Step 1: Identify async method usage

   send_text is an async method and must be awaited to run properly.

2. Step 2: Check code for await keyword

   The code calls send_text without await, causing coroutine not awaited error.

3. Final Answer:

   Missing await before connection.send_text causes coroutine not awaited error -> Option A

4. Quick Check:

   Async calls need await [OK]

Hint: Always await async send_text calls [OK]

Common Mistakes:

• Forgetting await on async methods
• Thinking send_text is synchronous
• Misunderstanding active_connections type

5. You want to broadcast messages to multiple clients but also remove disconnected clients automatically. Which approach best solves this in a FastAPI WebSocket manager?

hard

A. Use a global variable to track client count instead of connections

B. Wrap send_text in try-except; on exception remove client from active_connections

C. Clear active_connections list before every broadcast

D. Send messages without error handling; disconnected clients are ignored

Solution

1. Step 1: Understand client disconnection handling

   Disconnected clients cause send_text to raise exceptions when sending messages.

2. Step 2: Use try-except to catch exceptions and remove clients

   Wrapping send_text in try-except allows removing disconnected clients from active_connections.

3. Step 3: Evaluate other options

   Other approaches are inadequate: tracking client count with a global variable doesn't manage connections, sending without error handling lets exceptions propagate without cleanup, clearing the list discards active connections too.

4. Final Answer:

   Wrap send_text in try-except; on exception remove client from active_connections -> Option B

5. Quick Check:

   Handle errors to remove disconnected clients [OK]

Hint: Use try-except to remove disconnected clients during broadcast [OK]

Common Mistakes:

• Ignoring exceptions during send
• Clearing all clients mistakenly
• Tracking count instead of connections