ASGI vs WSGI in Django - Visual Side-by-Side Comparison

Concept Flow - ASGI vs WSGI

Client sends HTTP request

↓

WSGI Server receives request

↓

WSGI calls Django app synchronously

↓

Django processes request and returns response

↓

WSGI sends response back to client

↓

Client sends HTTP or WebSocket request

↓

ASGI Server receives request

↓

ASGI calls Django app asynchronously

↓

Django processes request (HTTP or WebSocket)

↓

ASGI sends response back to client

This flow shows how WSGI handles synchronous HTTP requests only, while ASGI handles asynchronous HTTP and WebSocket requests.

Execution Sample

Django

def wsgi_app(environ, start_response):
    response_body = b"Hello WSGI"
    start_response('200 OK', [('Content-Type', 'text/plain')])
    return [response_body]

async def asgi_app(scope, receive, send):
    # handle HTTP or WebSocket asynchronously
    pass

This code shows a simple WSGI synchronous app and an ASGI asynchronous app handling requests.

Execution Table

Step	Server Type	Request Type	Call Type	Django Processing	Response Sent
1	WSGI	HTTP	Synchronous call	Process HTTP request synchronously	Send HTTP response
2	ASGI	HTTP	Asynchronous call	Process HTTP request asynchronously	Send HTTP response
3	ASGI	WebSocket	Asynchronous call	Process WebSocket connection asynchronously	Send WebSocket messages
4	WSGI	WebSocket	N/A	Cannot handle WebSocket	No response (unsupported)

💡 WSGI stops at step 4 because it cannot handle WebSocket connections; ASGI supports both HTTP and WebSocket asynchronously.

Variable Tracker

Variable	WSGI Request	ASGI HTTP Request	ASGI WebSocket Request
Request Type	HTTP only	HTTP	WebSocket
Call Mode	Synchronous	Asynchronous	Asynchronous
Response Type	HTTP Response	HTTP Response	WebSocket Messages

Key Moments - 2 Insights

Why can't WSGI handle WebSocket connections?

WSGI is designed for synchronous HTTP requests only, so it cannot manage the persistent, two-way communication WebSockets require, as shown in execution_table row 4.

What does asynchronous call mean in ASGI?

It means ASGI can pause and resume handling requests, allowing multiple connections at once, unlike WSGI's synchronous blocking calls, as seen in execution_table rows 2 and 3.

Visual Quiz - 3 Questions

Look at the execution table, which server type supports WebSocket requests?

A ASGI

B Both WSGI and ASGI

C WSGI

D Neither

💡 Hint

Check the 'Request Type' and 'Server Type' columns in execution_table rows 3 and 4.

At which step does the server handle the request asynchronously?

A Step 2

B Step 1

C Step 4

D Step 3

💡 Hint

Look at the 'Call Type' column in execution_table for steps with 'Asynchronous call'.

If WSGI could handle WebSocket, which row would change in the execution table?

A Row 1

B Row 3

C Row 4

D Row 2

💡 Hint

Look at the row where WSGI cannot handle WebSocket (row 4).

Concept Snapshot

ASGI vs WSGI in Django:
- WSGI handles synchronous HTTP requests only.
- ASGI supports asynchronous HTTP and WebSocket.
- ASGI allows multiple connections at once.
- Use ASGI for real-time features like WebSockets.
- WSGI is simpler but limited to HTTP sync calls.

Full Transcript

This visual execution compares ASGI and WSGI servers in Django. WSGI handles HTTP requests synchronously, meaning it processes one request at a time and cannot handle WebSocket connections. ASGI handles requests asynchronously, allowing it to manage HTTP and WebSocket connections simultaneously. The execution table shows steps where WSGI processes HTTP synchronously and fails on WebSocket, while ASGI processes both asynchronously. Variables track request types and call modes. Key moments clarify why WSGI can't handle WebSocket and what asynchronous calls mean. The quiz tests understanding of server capabilities and call types. This helps beginners see how Django apps handle different connection types with these servers.