How a Request Reaches Your View
WSGI, the URL resolver, and the path to your code.
How a Request Reaches Your View is a free Django Academy lesson on CoddyKit — lesson 1 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Django Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
It Starts with a Click
Every Django page begins as an HTTP request. A browser asks for a URL, and Django's job is to answer with a response. 🌐
The Web Server Out Front
A web server like Nginx receives the raw request first. It handles networking, then hands the request off to Django to do the real work.
WSGI: The Handshake
WSGI is the standard interface between the web server and Django. It turns the incoming request into something your Python code can read.
The WSGI Application
Django ships a callable in wsgi.py. The server calls it for each request, and Django takes over from there to route and respond.
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()Middleware Runs First
Before your view, the request passes through middleware. Each layer can inspect or tweak the request, like adding security checks.
The URL Resolver
Django reads urls.py and matches the requested path against your patterns. The first pattern that matches wins the request.
urlpatterns = [
path('about/', views.about),
]Matching the Path
If the path is /about/, Django finds the matching pattern and notes which view should handle it. No match means a 404.
Calling Your View
Django calls your view function and passes it the request object. This is where your own code finally takes control.
def about(request):
return HttpResponse("Hi")The View Returns a Response
Your view must return an HttpResponse. Django takes that object and hands it back up the chain toward the browser.
Back Through Middleware
The response travels back through middleware in reverse order. Layers can add headers or compress content before it leaves.
Out to the Browser
The web server sends the finished response across the network. The browser renders it, completing one full request cycle. ✅
Quick Check
Which component matches the requested path to a view?
Recap: The Journey
A request flows from server to WSGI, through middleware, to the URL resolver, then your view, and back out as a response. That loop is Django. 🎉
Frequently asked questions
Is the “How a Request Reaches Your View” lesson free?
Yes — the full text of “How a Request Reaches Your View” is free to read here on the web, and the Django Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Django Academy course, upgrade to CoddyKit PRO.
What will I learn in “How a Request Reaches Your View”?
WSGI, the URL resolver, and the path to your code. You practise Django Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Django Academy?
No prior experience is required. Django Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 1 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “How a Request Reaches Your View” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Django Academy lesson?
Yes. Every Django Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- How a Request Reaches Your View
- The HttpRequest Object
- Returning an HttpResponse
- Status Codes and HttpResponse Subclasses