Why middleware matters in Django - Visual Breakdown

Concept Flow - Why middleware matters in Django

Request from User

↓

Middleware 1: Process Request

↓

Middleware 2: Process Request

↓

View Function Executes

↓

Middleware 2: Process Response

↓

Middleware 1: Process Response

↓

Response to User

Middleware acts like a chain of helpers that process requests before the view runs and responses before they go back to the user.

Execution Sample

Django

def simple_middleware(get_response):
    def middleware(request):
        print('Before view')
        response = get_response(request)
        print('After view')
        return response
    return middleware

This middleware prints messages before and after the view function runs.

Execution Table

Step	Action	Output	Notes
1	Request received by Middleware 1	Prints 'Before view'	Middleware starts processing request
2	Request passed to Middleware 2	Prints 'Before view'	Next middleware processes request
3	Request passed to View	View returns response	View handles request
4	Response passed back to Middleware 2	Prints 'After view'	Middleware processes response
5	Response passed back to Middleware 1	Prints 'After view'	Middleware processes response
6	Response sent to user	Response delivered	Request cycle complete

💡 Response sent back to user after passing through all middleware layers

Variable Tracker

Variable	Start	After Middleware 1 Request	After Middleware 2 Request	After View	After Middleware 2 Response	After Middleware 1 Response	Final
request	User request	Processed by Middleware 1	Processed by Middleware 2	Handled by View	Passing back	Passing back	Sent to user
response	None	None	None	View response	Processed by Middleware 2	Processed by Middleware 1	Final response

Key Moments - 2 Insights

Why do middleware process requests before the view and responses after the view?

Middleware wrap around the view like layers. They can modify or check the request before the view runs and change the response after the view returns, as shown in steps 1-5 in the execution_table.

Can middleware stop a request before it reaches the view?

Yes, middleware can return a response early, skipping the view. This is possible because middleware runs before the view, as seen in the request processing steps 1 and 2.

Visual Quiz - 3 Questions

Look at the execution_table, what is printed first when a request comes in?

A 'Before view' from Middleware 2

B 'After view' from Middleware 1

C 'Before view' from Middleware 1

D 'After view' from Middleware 2

💡 Hint

Check step 1 and 2 in the execution_table to see the order of prints.

At which step does the view function execute?

A Step 3

B Step 2

C Step 4

D Step 5

💡 Hint

Look for the step where the view returns a response in the execution_table.

If Middleware 2 did not process the response, which step would be missing?

A Step 5

B Step 4

C Step 3

D Step 6

💡 Hint

Check which step shows Middleware 2 processing the response in the execution_table.

Concept Snapshot

Middleware in Django wraps requests and responses.
They run code before the view handles the request and after the view returns a response.
This lets you modify or check requests and responses easily.
Middleware form a chain that every request and response passes through.
They help add features like security, logging, or session handling.

Full Transcript

Middleware in Django is a way to process requests and responses globally. When a user sends a request, it first passes through middleware layers before reaching the view function. Each middleware can modify or check the request. After the view processes the request and returns a response, the response passes back through the middleware layers in reverse order. This lets middleware add features like security checks, logging, or modifying responses. The example code shows middleware printing messages before and after the view runs. The execution table traces each step from request arrival, through middleware, to the view, and back through middleware to the user. Variables like request and response change as they move through middleware and the view. Understanding this flow helps beginners see why middleware matters and how it fits in Django's request handling.

Practice

1. What is the main purpose of middleware in a Django application?

easy

A. To process requests and responses globally before reaching views

B. To define database models and relationships

C. To create HTML templates for rendering pages

D. To handle user authentication only

Solution

1. Step 1: Understand middleware role

   Middleware acts on requests and responses before and after views run.

2. Step 2: Compare options to middleware function

   Only To process requests and responses globally before reaching views describes processing requests and responses globally, which matches middleware's purpose.

3. Final Answer:

   To process requests and responses globally before reaching views -> Option A

4. Quick Check:

   Middleware = global request/response processing [OK]

Hint: Middleware acts on requests/responses before views [OK]

Common Mistakes:

• Confusing middleware with models or templates
• Thinking middleware only handles authentication
• Assuming middleware runs after views only

2. Which of the following is the correct way to add a custom middleware class in Django's settings?

easy

A. Add 'myapp.middleware.MyMiddleware' to TEMPLATES list

B. Add 'myapp.middleware.MyMiddleware' to MIDDLEWARE list in settings.py

C. Add 'myapp.middleware.MyMiddleware' to INSTALLED_APPS list

D. Add 'myapp.middleware.MyMiddleware' to DATABASES dictionary

Solution

1. Step 1: Identify where middleware is configured

   Django uses the MIDDLEWARE list in settings.py to register middleware classes.

2. Step 2: Match the correct setting for middleware

   Only Add 'myapp.middleware.MyMiddleware' to MIDDLEWARE list in settings.py correctly adds the middleware class path to the MIDDLEWARE list.

3. Final Answer:

   Add 'myapp.middleware.MyMiddleware' to MIDDLEWARE list in settings.py -> Option B

4. Quick Check:

   Middleware goes in MIDDLEWARE list [OK]

Hint: Middleware classes go in MIDDLEWARE list, not INSTALLED_APPS [OK]

Common Mistakes:

• Adding middleware to INSTALLED_APPS instead of MIDDLEWARE
• Placing middleware in TEMPLATES or DATABASES settings
• Using incorrect string format for middleware path

3. Given this middleware code snippet, what will be printed when a request is processed?

class LogMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        print('Before view')
        response = self.get_response(request)
        print('After view')
        return response

medium

A. Before view printed before the view runs, After view printed after

B. Only Before view is printed

C. Only After view is printed

D. No output is printed

Solution

1. Step 1: Analyze __call__ method flow

   The middleware prints 'Before view', calls the view via get_response, then prints 'After view'.

2. Step 2: Understand order of prints

   'Before view' prints before the view runs, 'After view' prints after the view returns.

3. Final Answer:

   Before view printed before the view runs, After view printed after -> Option A

4. Quick Check:

   Middleware prints before and after view [OK]

Hint: Middleware __call__ runs code before and after get_response [OK]

Common Mistakes:

• Thinking only one print runs
• Confusing order of prints
• Assuming middleware skips printing

4. You wrote this middleware but it causes an error:

class ErrorMiddleware:
    def __init__(self, get_response):
        pass

    def __call__(self, request):
        return self.get_response(request)

What is the problem?

medium

A. Middleware classes must inherit from a base class

B. The __call__ method should not return anything

C. The __init__ method does not save get_response, causing AttributeError

D. The __init__ method should not have parameters

Solution

1. Step 1: Check __init__ method implementation

   The __init__ method ignores get_response and does not save it as self.get_response.

2. Step 2: Understand __call__ method usage

   __call__ tries to call self.get_response, but it does not exist, causing an AttributeError.

3. Final Answer:

   The __init__ method does not save get_response, causing AttributeError -> Option C

4. Quick Check:

   Save get_response in __init__ to avoid errors [OK]

Hint: Always save get_response in __init__ as self.get_response [OK]

Common Mistakes:

• Not storing get_response in __init__
• Assuming __call__ doesn't need to return response
• Thinking middleware must inherit from a base class

5. You want to create middleware that adds a custom header X-App-Version with value 1.0 to every response. Which code snippet correctly implements this?

hard

A. class VersionMiddleware:
def __init__(self, get_response):
self.get_response = get_response
def process_response(self, request, response):
response['X-App-Version'] = '1.0'
return response

B. class VersionMiddleware:
def __init__(self, get_response):
self.get_response = get_response
def process_request(self, request):
request['X-App-Version'] = '1.0'

C. class VersionMiddleware:
def __init__(self, get_response):
self.get_response = get_response
def __call__(self, request):
request['X-App-Version'] = '1.0'
return self.get_response(request)

D. class VersionMiddleware:
def __init__(self, get_response):
self.get_response = get_response
def __call__(self, request):
response = self.get_response(request)
response['X-App-Version'] = '1.0'
return response

Solution

1. Step 1: Identify where to add headers in middleware

   Headers must be added to the response object after the view runs, inside __call__.

2. Step 2: Check each option's method

   class VersionMiddleware:
       def __init__(self, get_response):
           self.get_response = get_response
       def __call__(self, request):
           response = self.get_response(request)
           response['X-App-Version'] = '1.0'
           return response

   correctly adds the header after calling get_response and returns the modified response.

3. Final Answer:

   correctly adds the header in __call__ after response creation -> Option D

4. Quick Check:

   Add headers after get_response in __call__ [OK]

Hint: Modify response headers after get_response call in __call__ [OK]

Common Mistakes:

• Trying to add headers to request instead of response
• Using process_request which can't modify response
• Not returning the response object