Why WebSockets enable real-time communication in FastAPI - Visual Breakdown

Concept Flow - Why WebSockets enable real-time communication

Client sends HTTP request to server

↓

Server upgrades connection to WebSocket

↓

Open two-way communication channel

↓

Client and Server can send messages anytime

↓

Messages received instantly without new HTTP requests

↓

Connection stays open until closed by either side

The flow shows how a normal HTTP request upgrades to a WebSocket connection, enabling continuous two-way messaging without repeated requests.

Execution Sample

FastAPI

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'Received: {data}')

This FastAPI code opens a WebSocket endpoint that accepts a connection, receives a message, and sends a response back immediately.

Execution Table

Step	Action	State Before	State After	Message Sent/Received
1	Client sends HTTP request to /ws	No connection	Request received	None
2	Server upgrades to WebSocket	Request received	WebSocket connection open	None
3	Server accepts connection	WebSocket connection open	Connection accepted	None
4	Client sends message 'Hello'	Connection accepted	Message received	Hello
5	Server sends response	Message received	Response sent	Received: Hello
6	Connection remains open	Response sent	Connection open	None
7	Client or server closes connection	Connection open	Connection closed	None

💡 Connection closes when either client or server ends it, stopping real-time communication.

Variable Tracker

Variable	Start	After Step 3	After Step 4	After Step 5	Final
websocket.connection_state	None	Open	Open	Open	Closed
message_received	None	None	'Hello'	'Hello'	None
message_sent	None	None	None	'Received: Hello'	None

Key Moments - 3 Insights

Why does the connection stay open after the first message?

Because WebSocket upgrades the HTTP connection to a persistent two-way channel, allowing multiple messages without reconnecting, as shown in steps 4-6 in the execution_table.

How does the server know when to send a message back?

The server waits for a message from the client (step 4), then immediately sends a response (step 5), demonstrating real-time interaction.

What happens if the client sends another message after step 5?

The connection is still open (step 6), so the server can receive and respond again without a new HTTP request.

Visual Quiz - 3 Questions

Look at the execution_table, what is the connection state after step 3?

A HTTP request pending

B WebSocket connection is open

C Connection is closed

D No connection exists

💡 Hint

Check the 'State After' column for step 3 in the execution_table.

At which step does the server send a message back to the client?

A Step 5

B Step 4

C Step 6

D Step 7

💡 Hint

Look for 'Message Sent/Received' column showing a message sent by the server.

If the client never closes the connection, what happens to the connection state after step 6?

A Server closes connection after timeout

B Connection closes automatically

C Connection remains open for more messages

D Connection resets to HTTP

💡 Hint

Refer to the 'State After' column in step 6 and the exit_note.

Concept Snapshot

WebSockets start as HTTP requests that upgrade to a persistent two-way channel.
This lets client and server send messages anytime without reconnecting.
The connection stays open until closed by either side.
FastAPI handles this with @app.websocket and async functions.
This enables real-time communication like chat or live updates.

Full Transcript

WebSockets enable real-time communication by upgrading a normal HTTP request to a persistent two-way connection. In FastAPI, this is done using the @app.websocket decorator. The server accepts the WebSocket connection, then both client and server can send messages instantly without needing new HTTP requests. The connection remains open until closed by either side, allowing continuous real-time data exchange. This is shown step-by-step in the execution table, where the client sends a message, the server receives and responds immediately, and the connection stays open for more messages.

Practice

1. Why do WebSockets enable real-time communication in FastAPI applications?

easy

A. Because they only send data from server to client once

B. Because they use HTTP requests repeatedly to fetch new data

C. Because they keep a constant open connection for instant two-way data exchange

D. Because they require manual page refresh to update data

Solution

1. Step 1: Understand WebSocket connection behavior

   WebSockets maintain a persistent connection allowing continuous data flow without reconnecting.

2. Step 2: Compare with HTTP request-response model

   Unlike HTTP, which closes after each request, WebSockets allow instant two-way communication.

3. Final Answer:

   Because they keep a constant open connection for instant two-way data exchange -> Option C

4. Quick Check:

   Persistent connection = real-time communication [OK]

Hint: Remember: WebSockets keep connection open for instant updates [OK]

Common Mistakes:

• Confusing WebSockets with repeated HTTP requests
• Thinking WebSockets only send data one way
• Assuming page refresh is needed for updates

2. Which of the following is the correct way to define a WebSocket route in FastAPI?

easy

A. app.websocket('/ws') async def websocket_endpoint(websocket): await websocket.accept()

B. app.get('/ws') async def websocket_endpoint(websocket): await websocket.accept()

C. app.post('/ws') def websocket_endpoint(websocket): websocket.accept()

D. app.websocket('/ws') def websocket_endpoint(): websocket.accept()

Solution

1. Step 1: Identify correct decorator and async function

   FastAPI uses @app.websocket decorator and async def for WebSocket routes.

2. Step 2: Confirm usage of await websocket.accept()

   Accepting the connection requires awaiting websocket.accept() inside async function.

3. Final Answer:

   app.websocket('/ws') async def websocket_endpoint(websocket): await websocket.accept() -> Option A

4. Quick Check:

   Use @app.websocket + async + await accept() [OK]

Hint: WebSocket routes need @app.websocket and async functions [OK]

Common Mistakes:

• Using HTTP method decorators like @app.get for WebSockets
• Forgetting async or await keywords
• Defining function without websocket parameter

3. Given this FastAPI WebSocket code snippet, what will the client receive after sending 'hello'?

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'Received: {data}')

medium

A. 'hello'

B. Error: websocket not accepted

C. No response, connection closed

D. 'Received: hello'

Solution

1. Step 1: Analyze the receive and send calls

   The server waits for text, receives 'hello', then sends back 'Received: hello'.

2. Step 2: Confirm connection acceptance

   websocket.accept() is awaited, so connection is open and ready for communication.

3. Final Answer:

   'Received: hello' -> Option D

4. Quick Check:

   Server echoes with prefix 'Received:' [OK]

Hint: Look for send_text with formatted string after receive_text [OK]

Common Mistakes:

• Assuming no response is sent
• Ignoring the awaited accept() call
• Confusing received data with sent data

4. What is wrong with this FastAPI WebSocket handler code?

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

medium

A. Incorrect route decorator used

B. Calling receive_text before accepting the connection

C. Using send_text instead of send_bytes

D. Missing async keyword in function definition

Solution

1. Step 1: Check order of accept and receive calls

   WebSocket connection must be accepted before receiving data.

2. Step 2: Identify the error caused by wrong order

   Calling receive_text before accept() causes runtime error as connection is not open yet.

3. Final Answer:

   Calling receive_text before accepting the connection -> Option B

4. Quick Check:

   Accept connection before receiving data [OK]

Hint: Always await websocket.accept() before receiving messages [OK]

Common Mistakes:

• Receiving data before accepting connection
• Forgetting async keyword
• Confusing send_text with send_bytes

5. You want to build a live chat app using FastAPI WebSockets. Which approach best ensures real-time updates to all connected clients?

hard

A. Keep a list of connected WebSocket objects and broadcast messages to all

B. Send HTTP requests every second to fetch new messages

C. Open a new WebSocket connection for each message sent

D. Use a database trigger to push messages without WebSockets

Solution

1. Step 1: Understand real-time broadcast requirement

   To update all clients instantly, server must send messages to all open connections.

2. Step 2: Identify best method for broadcasting

   Maintaining a list of connected WebSocket objects allows sending messages to all clients immediately.

3. Final Answer:

   Keep a list of connected WebSocket objects and broadcast messages to all -> Option A

4. Quick Check:

   Broadcast via open WebSocket connections = real-time updates [OK]

Hint: Broadcast by storing and sending to all connected sockets [OK]

Common Mistakes:

• Using repeated HTTP polling instead of WebSockets
• Opening new connections per message wastes resources
• Relying on database triggers without WebSocket communication