00. Django — ELI5¶
Django is a strict office manager who insists every request walks through the same hallway, in the same order, every time. New developers think Django is magic. It is not magic. It is a long hallway with named doors, and each door does one specific job before passing you to the next.
Picture an office building with one entrance. Visitors come in carrying request slips.
The receptionist (the WSGI/ASGI server — gunicorn, uvicorn) accepts the visitor and hands the slip to the manager. The manager walks the visitor down a hallway with named doors.
First door: security check — middleware. The manager runs the slip past every middleware on the way in, and again on the way out. Some doors check the visitor's badge (authentication). Some doors note the visit (request logging). Some doors refuse certain visitors (CSRF, rate limiting).
Second door: routing — the URLconf. The manager reads the slip's address ("/orders/1234/") and consults the directory. The directory says "go to room 412." That's a view function.
Third door: the view — your Python function. The view reads the slip, asks the file room (the database, via the ORM) for the right binder, decides what to write back, and hands the manager a response slip.
Fourth door: the template (optional). If the view wants to render HTML, it takes its data plus an HTML template and fills in the blanks. The result is the page the visitor will read.
The response slip walks back down the hallway, past every middleware in reverse. The receptionist hands it to the visitor.
That's it. Hallway. Doors. Slips. Every Django request, every time.
The recurring vocabulary¶
| Name | What it is |
|---|---|
| WSGI server | gunicorn, uwsgi — accepts HTTP, hands the request to Django |
| middleware | a chain of pre/post hooks every request walks through |
| URLconf | the directory mapping URL patterns to view functions |
| view | the Python function that produces a response from a request |
| ORM | the layer that turns Python model classes into SQL |
| template | the HTML file with {{ variable }} placeholders |
| migration | a versioned script that evolves the database schema |
| manager | the Model.objects attribute through which you query |
| signal | a pub/sub hook fired on lifecycle events (pre_save, post_save) |
| admin | the auto-generated CRUD UI over your models |
The picture¶
client (browser, curl, mobile app)
│
▼ HTTP
┌──────────────────────┐
│ gunicorn / uvicorn │ N worker processes
└──────────┬───────────┘
│ WSGI/ASGI call
▼
┌──────────────────────────────────────────┐
│ Django application │
│ │
│ request response │
│ │ ▲ │
│ ▼ │ │
│ ┌─────────────────────────────┐ │ │
│ │ middleware (entering) │ │ │
│ └────────────┬────────────────┘ │ │
│ │ │ │
│ ▼ │ │
│ ┌─────────────────────────────┐ │ │
│ │ URLconf (routing) │ │ │
│ └────────────┬────────────────┘ │ │
│ │ │ │
│ ▼ │ │
│ ┌─────────────────────────────┐ │ │
│ │ view function │ │ │
│ │ - ORM queries │ │ │
│ │ - business logic │ │ │
│ │ - render template (opt) │ │ │
│ └────────────┬────────────────┘ │ │
│ │ response │ │
│ ▼ │ │
│ ┌─────────────────────────────┐ │ │
│ │ middleware (exiting) │──┘ │
│ └─────────────────────────────┘ │
└──────────────────────────────────────────┘
│
▼ SQL
┌──────────────────────┐
│ Postgres / MySQL │
└──────────────────────┘
The hallway is sequential. Every request walks the same path. The configuration of the doors — which middleware, which URLs, which models — is your app.
Two facts that surprise new Django developers¶
The ORM is lazy. Order.objects.filter(status='paid') does not run a query. It returns a QuerySet. The query runs when you iterate the QuerySet, call len(), slice it, or call .first(). This is why you can chain .filter().filter().order_by().select_related() — each call adds to the plan; the SQL is built on first evaluation.
Migrations are code. When you change a model field, Django does not change the database. You run manage.py makemigrations — Django diffs the model state against the previous migration and writes a new migration file (Python code, not SQL). You then run manage.py migrate to apply it. The migration files are committed to git. The database state is the sum of applied migrations.
What this module covers¶
- 01-orm-request-cycle-internals.md — What the ORM actually does, the request lifecycle in detail, lazy QuerySets, prefetch, and N+1.
- 02-models-views-routing-day-to-day.md — Defining models, writing views (function and class-based), URL routing, forms, templates.
- 03-deployment-scaling-prod-gotchas.md — Gunicorn workers, static files, database pooling, caching, async, the things that go wrong in production.
What this module is not about¶
- Django REST Framework specifics. DRF builds on Django; this module is the base.
- Django Channels (WebSockets). Async Django and Channels are a track of their own.
- CMS-specific patterns (Wagtail, Mezzanine). Built on Django but not Django itself.
Bridge. The hallway picture is enough to believe Django works. It is not enough to debug a slow page or diagnose an ORM bug. Chapter 01 opens one request and follows it through the ORM, the cache, and the response. → 01-orm-request-cycle-internals.md