Bird
Raised Fist0
Djangoframework~10 mins

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

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
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
StepServer TypeRequest TypeCall TypeDjango ProcessingResponse Sent
1WSGIHTTPSynchronous callProcess HTTP request synchronouslySend HTTP response
2ASGIHTTPAsynchronous callProcess HTTP request asynchronouslySend HTTP response
3ASGIWebSocketAsynchronous callProcess WebSocket connection asynchronouslySend WebSocket messages
4WSGIWebSocketN/ACannot handle WebSocketNo response (unsupported)
💡 WSGI stops at step 4 because it cannot handle WebSocket connections; ASGI supports both HTTP and WebSocket asynchronously.
Variable Tracker
VariableWSGI RequestASGI HTTP RequestASGI WebSocket Request
Request TypeHTTP onlyHTTPWebSocket
Call ModeSynchronousAsynchronousAsynchronous
Response TypeHTTP ResponseHTTP ResponseWebSocket 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
Test your understanding
Look at the execution table, which server type supports WebSocket requests?
AASGI
BBoth WSGI and ASGI
CWSGI
DNeither
💡 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?
AStep 2
BStep 1
CStep 4
DStep 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?
ARow 1
BRow 3
CRow 4
DRow 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.

Practice

(1/5)
1. What is the main difference between WSGI and ASGI in Django?
easy
A. WSGI is faster than ASGI in all cases.
B. WSGI supports WebSocket, ASGI only supports HTTP.
C. WSGI is used for databases, ASGI is used for templates.
D. WSGI handles synchronous requests, ASGI supports asynchronous and real-time features.

Solution

  1. Step 1: Understand WSGI's role

    WSGI is designed for synchronous web applications, handling one request at a time.
  2. Step 2: Understand ASGI's role

    ASGI supports asynchronous code and real-time features like WebSocket, allowing multiple requests concurrently.
  3. Final Answer:

    WSGI handles synchronous requests, ASGI supports asynchronous and real-time features. -> Option D
  4. Quick Check:

    WSGI = synchronous, ASGI = asynchronous [OK]
Hint: Remember: ASGI = async and real-time support [OK]
Common Mistakes:
  • Thinking WSGI supports WebSocket
  • Confusing ASGI with database handling
  • Assuming WSGI is always faster
2. Which of the following is the correct way to specify an ASGI application in Django's asgi.py file?
easy
A. application = get_wsgi_application()
B. application = get_application()
C. application = get_asgi_application()
D. application = asgi_application()

Solution

  1. Step 1: Recall Django's ASGI setup

    Django provides get_asgi_application() to create the ASGI application instance.
  2. Step 2: Compare options

    get_wsgi_application() is for WSGI, others are incorrect function names.
  3. Final Answer:

    application = get_asgi_application() -> Option C
  4. Quick Check:

    ASGI uses get_asgi_application() [OK]
Hint: ASGI uses get_asgi_application(), WSGI uses get_wsgi_application() [OK]
Common Mistakes:
  • Using get_wsgi_application() in asgi.py
  • Misspelling function names
  • Confusing application variable names
3. Given this Django ASGI consumer code snippet, what will happen when a WebSocket connection is accepted?
from channels.generic.websocket import AsyncWebsocketConsumer

class ChatConsumer(AsyncWebsocketConsumer):
    async def connect(self):
        await self.accept()
medium
A. The server will crash due to missing HTTP response.
B. The WebSocket connection is accepted and ready to receive messages asynchronously.
C. The connection will be rejected because accept() is synchronous.
D. Nothing happens because connect() is not called automatically.

Solution

  1. Step 1: Understand AsyncWebsocketConsumer behavior

    The connect method is called automatically on WebSocket connection attempts.
  2. Step 2: Analyze the accept() call

    Calling await self.accept() accepts the WebSocket connection asynchronously, enabling message exchange.
  3. Final Answer:

    The WebSocket connection is accepted and ready to receive messages asynchronously. -> Option B
  4. Quick Check:

    Async accept() means connection accepted [OK]
Hint: Async accept() means WebSocket connection is accepted [OK]
Common Mistakes:
  • Thinking accept() is synchronous
  • Assuming connect() is not called automatically
  • Confusing WebSocket with HTTP requests
4. You wrote this snippet in your Django asgi.py file but get an error:
from django.core.asgi import get_asgi_application

application = get_wsgi_application()

What is the problem?
medium
A. You imported get_asgi_application but called get_wsgi_application, causing a NameError.
B. You must import get_wsgi_application to use it.
C. The application variable name is incorrect.
D. There is no problem; this code works fine.

Solution

  1. Step 1: Check imports and function calls

    The code imports get_asgi_application but calls get_wsgi_application(), which is not imported.
  2. Step 2: Understand the error cause

    This mismatch causes a NameError because get_wsgi_application is undefined in this context.
  3. Final Answer:

    You imported get_asgi_application but called get_wsgi_application, causing a NameError. -> Option A
  4. Quick Check:

    Import and call must match [OK]
Hint: Import and function call must match exactly [OK]
Common Mistakes:
  • Calling a function not imported
  • Mixing ASGI and WSGI functions
  • Assuming variable name causes error
5. You want to build a Django app that supports both HTTP requests and WebSocket connections for chat. Which setup should you choose and why?
hard
A. Use ASGI because it supports asynchronous HTTP and WebSocket connections.
B. Use WSGI because it handles HTTP and WebSocket natively.
C. Use WSGI with a separate WebSocket server.
D. Use ASGI but disable asynchronous features for compatibility.

Solution

  1. Step 1: Identify requirements

    The app needs to handle HTTP requests and WebSocket connections for chat, which requires async support.
  2. Step 2: Match server capabilities

    WSGI only supports synchronous HTTP, no WebSocket support. ASGI supports both async HTTP and WebSocket natively.
  3. Step 3: Evaluate options

    Use ASGI because it supports asynchronous HTTP and WebSocket connections. correctly chooses ASGI for full async and WebSocket support in one server.
  4. Final Answer:

    Use ASGI because it supports asynchronous HTTP and WebSocket connections. -> Option A
  5. Quick Check:

    ASGI supports async HTTP + WebSocket [OK]
Hint: ASGI supports both HTTP and WebSocket asynchronously [OK]
Common Mistakes:
  • Assuming WSGI supports WebSocket
  • Using separate servers unnecessarily
  • Disabling async features in ASGI