This is one of four courses building the exact same app in four genuinely different architectures — Food Tracker (FastAPI), Food Tracker (React + Express), and Food Tracker (React + Firebase) are its siblings. Every one of them scans a barcode, tracks a use-by date, and alerts before something goes to waste. This course's own answer leans all the way into the opposite philosophy from its FastAPI sibling: one single, integrated framework, rather than a thin layer you assemble yourself from smaller pieces.

What the App Actually Does

The shared spec every course in the quartet builds toward:

• Scan a barcode with a phone or webcam camera, look it up against Open Food Facts (free, open, no API key) to fetch the product's name and details automatically.
• Record a use-by date for the item, and see it flagged once it's expiring soon.
• Keep a full history of every item ever added — some still active with a real expiry date, some already marked used with no expiry date at all — searchable in real time as you type.
• Look up recipes via TheMealDB (also free, no key) that use ingredients close to expiring.

A weekly meal planner is explicitly out of scope for all four courses — named future work, not something any of them will build.

Batteries Included, vs. a Thin API Layer

FastAPI, this quartet's other Python course, gives you essentially one thing: a fast, well-typed way to define HTTP routes. Everything else — the database layer, the templating, an admin interface — is a separate library you choose and wire in yourself. Django takes the opposite position entirely: an ORM, a templating engine, a full admin interface, a forms system, and authentication all ship together, pre-integrated, from the very first startproject command. Neither philosophy is simply "better" — they represent two real, different answers to how much a framework should decide for you up front.

Project vs. App: Two Different Things

A Django project (foodtracker) is the overall configuration — settings, URL routing, WSGI/ASGI entry points. An app (pantry) is a self-contained component holding its own models, views, and templates for one piece of functionality. A single project can hold several apps; this course's entire feature set lives inside one, pantry, since the app is genuinely small enough not to need splitting further.

MVT: Model-View-Template

Django's own name for its architecture is MVT, not the more familiar MVC — and the naming difference matters, because it's a real, common point of confusion. Django's Model is the ORM layer, same idea as MVC's Model. Django's Template is the presentation layer, same idea as MVC's View. Django's own View, confusingly, is actually the controller in classic MVC terms — the Python function or class that receives a request, talks to the Model, and picks a Template to render. Anyone arriving from traditional MVC terminology (or from FastAPI, which has no equivalent three-part naming at all) has to consciously remember that Django's "View" isn't what "view" means almost everywhere else.

Setting Up and Running It

SQLite is the genuine, appropriate choice here, not a placeholder to "upgrade later" — this is a personal, single-user app, exactly the case SQLite was designed for.

Where This Course Is Headed

Modeling the Pantry Item with Django's ORM, the Django admin as an instant CRUD tool, barcode lookup via a Django view, camera-based scanning, the add-item flow via Django Forms, expiry alerts, item history and search, marking items used, recipe lookup, Django REST Framework for the interactive features that need real JSON, deployment, and a capstone.

Hands-On Exercises

Chapter 1 set up the project and the app. This chapter defines the one Model that everything else in this course builds on.

The Model

null=True and blank=True Are Two Different Settings

null=True is a database-level setting — it lets the actual SQL column store NULL. blank=True is a form/admin-level setting — it lets Django's forms and the admin site accept an empty value without raising a validation error. They're independent, and both are needed on expiry_date for two separate reasons: null=True so a used item's row can genuinely have no expiry date stored, and blank=True so the admin form doesn't reject an empty expiry date as a validation failure, even though the database would happily accept it.

This app's own Firestore-based sibling course models the identical "no expiry" case by omitting the field from the document entirely — a genuine structural difference between schema-on-write (this course: an always-present column, sometimes holding NULL) and schema-on-read (that course: the field simply isn't there at all).

DateField vs. DateTimeField

expiry_date uses DateField — a use-by date has no meaningful time component. added_at and used_at use DateTimeField, since knowing roughly when within a day something happened is genuinely useful for those two fields specifically.

auto_now_add: Django's Own Trustworthy Timestamp

auto_now_add=True sets a field's value once, at creation, using the server's own clock — and makes the field non-editable through ordinary forms. This solves the identical problem the Firebase sibling course's own serverTimestamp() solves: never trust a client-supplied creation time. auto_now_add is easy to confuse with the similarly-named auto_now, which instead updates the field on every save — the wrong choice for added_at, which should only ever be set the one time the row is created.

choices= Is a Voluntary Constraint, Not a Guarantee

STATUS_CHOICES restricts what the admin site and Django Forms will offer as valid options for status — but whether that also becomes a real database-level constraint depends on the Django version in use, and shouldn't be assumed either way without checking. A raw SQL statement, or code that bypasses Django's own forms and admin validation, may still be able to write a value outside STATUS_CHOICES depending on that. choices= is genuinely useful for guiding the admin and forms layer; treating it as an unconditional database-level guarantee is the kind of assumption worth verifying rather than trusting blindly.

Migrations: Two Separate Steps, On Purpose

makemigrations compares the current models against the last recorded schema state and generates a migration file — a versioned, reviewable Python description of the change. migrate is the separate step that actually applies pending migrations to a real database. Keeping "describe the change" and "apply the change" as two distinct commands means a migration file can be reviewed and committed to version control before it ever touches a database, and the exact same migration can be applied identically across a developer's machine, staging, and production.

Where This Course Is Headed

The Django admin as an instant CRUD tool for this exact model, barcode lookup via a Django view, camera-based scanning, the add-item flow via Django Forms, expiry alerts, item history and search, marking items used, recipe lookup, Django REST Framework, deployment, and a capstone.

Hands-On Exercises

Chapter 1 promised a working CRUD interface before writing any business logic at all. Here's that promise, delivered.

Registering the Model

createsuperuser creates the admin's own login account — a separate concept entirely from any future end-user account this app might have. Visiting /admin/ and signing in with it now shows a complete, working list/add/edit/delete interface for Item, generated from just those two lines of code.

Customizing It With ModelAdmin

Plain registration gives a genuinely functional but generic list view. A ModelAdmin subclass shapes it into something actually useful day to day:

• list_display — which columns actually show in the list view, instead of just each row's __str__.
• list_filter — a sidebar of quick filters, genuinely useful for jumping straight to, say, everything with status = "active".
• search_fields — the admin's own search box, which performs a real substring (SQL LIKE) match by default. Worth flagging honestly: this is a happy coincidence, not the same thing as the live search-as-you-type feature this course builds for the app itself later — the admin's search exists purely for the admin's own list view.
• readonly_fields — added_at is already non-editable (Chapter 2's auto_now_add implicitly sets editable=False), and Django's admin would normally just omit a non-editable field from the form entirely. Listing it in readonly_fields instead keeps its actual value visible — read-only — right there in the change form, rather than making it invisible.

A Real Tool, Not Just a Demo

Before Chapter 4's barcode lookup or Chapter 5's real add-item flow exist, this admin already lets real test Item rows be created by hand — genuinely useful for exercising Chapter 7's expiry query, or Chapter 8's search, against real data long before the app's own user-facing screens are built.

A Real Limit Worth Naming

The admin is a tool for whoever manages the site's data directly — it was never meant to be, and won't become, the pantry app's own end-user interface. There's no camera scanning here, no barcode-triggered lookup, no live search-as-you-type UX. Having a working admin is not the same as having a finished app; the two serve genuinely different audiences.

Where This Course Is Headed

Barcode lookup via a Django view, camera-based scanning, the add-item flow via Django Forms, expiry alerts, item history and search, marking items used, recipe lookup, Django REST Framework, deployment, and a capstone.

Hands-On Exercises

The admin gave a working CRUD interface for free. This chapter writes the first genuinely custom code in this course: a view that turns a scanned barcode into a real product name.

URLs and Views: Two Separate Files, on Purpose

Django deliberately keeps "which URL triggers this code" (urls.py) separate from "what that code actually does" (views.py) — two files, wired together explicitly. FastAPI's own decorator-based routing (@app.get("/path")) puts both in the same place, directly above the function it decorates. Neither is objectively better; it's a real, structural difference in where that one piece of wiring lives, worth knowing rather than assuming every framework does it the same way.

A Second Model: BarcodeCache

Open Food Facts needs no API key here either, so the same reasoning that justified a Cloud Function in this app's own Firebase sibling course applies again: caching, consistent error handling, future-proofing — nothing about secrecy.

Note primary_key=True on barcode here — the exact opposite of Chapter 2's own Item model, where barcode is deliberately an ordinary field, never the primary key, because the same product can be purchased and tracked more than once. BarcodeCache genuinely is one record per product, so keying it directly by barcode is correct here.

The View

Wiring the URL

<str:barcode> is Django's own path converter — it types and captures the URL segment directly inside the route pattern string, rather than as a Python function type annotation the way FastAPI declares a path parameter's type.

Migrating the New Model

requests Isn't a Django Battery

Worth being precise about what "batteries included" actually covers: Django ships an ORM, an admin, forms, and templating — everything for building the app's own request/response cycle. Making an outbound call to someone else's API is a different job entirely, and needs a separate library (pip install requests) regardless of how much Django itself provides natively.

Where This Course Is Headed

Camera-based barcode scanning, the add-item flow via Django Forms, expiry alerts, item history and search, marking items used, recipe lookup, Django REST Framework, deployment, and a capstone.

Hands-On Exercises

Chapter 4 built the endpoint; this chapter builds the page a phone camera actually talks to. The underlying browser APIs are identical to what this app's React-based sibling courses use — but how that code gets packaged looks genuinely different here.

A Template, Not a Component

Django has no equivalent of a portable React component or hook — no lightweight, reusable frontend unit that carries its own logic and can simply be dropped into two different apps unmodified. What it has instead is template inheritance and includes ({% extends %}, {% include %}) — a coarser-grained way to reuse markup, not JavaScript behavior. The scanning logic in this course lives as page-specific script inside one template, not as something this course could hand to a sibling the way the two React-based courses share one component outright.

The View

The Template

A Real Full-Page-Navigation Consequence

Detecting a barcode here navigates to an entirely new URL — a genuine server round-trip and full page reload, not an in-memory state update. This is a real, honest consequence of the server-rendered-template default, not a mistake: the two React-based sibling courses handle a successful scan by updating component state directly, with no navigation at all. Chapter 11's Django REST Framework chapter is exactly where this could change — a fetch() call to a JSON endpoint instead of a URL redirect would avoid the page reload entirely, at the cost of writing more client-side JavaScript to manage that state by hand.

Camera Cleanup: The Same Gotcha, a Genuinely Harder Problem Here

stream.getTracks().forEach(t => t.stop()) still has to run before the camera is released — same underlying requirement as any camera-scanning code, in any framework. But without a component lifecycle, this template can only reliably guarantee cleanup on the one exit path it explicitly coded: a successful scan. A user who instead clicks a "Cancel" link, uses the browser's back button, or simply closes the tab leaves the camera running, with no equivalent of a React useEffect cleanup function guaranteed to fire regardless of how the component goes away. This is a genuine structural disadvantage of the plain-template approach for this specific concern, not something this chapter glosses over.

BarcodeDetector Support: The Same Real Limitation

Chrome/Edge on Android and desktop support it natively; Safari on iOS does not, and needs the same ZXing fallback this app's React-based courses rely on. This is a browser API limitation, entirely independent of which backend framework is serving the page.

Where This Course Is Headed

The add-item flow via Django Forms, expiry alerts, item history and search, marking items used, recipe lookup, Django REST Framework — which directly revisits this chapter's own full-page-reload limitation — deployment, and a capstone.

Hands-On Exercises

Chapter 5's scan flow redirects here once a barcode's been looked up. This chapter builds the actual confirm-and-save step — and shows one of Django's most concrete "batteries included" payoffs yet.

ModelForm: Deriving a Form From the Model, Not Duplicating It

ModelForm generates both the form fields and their validation rules directly from Chapter 2's own Item model — max_length, blank, choices, all of it carries over automatically. FastAPI's own equivalent needs a separate Pydantic schema class, hand-written to mirror the same fields the SQLAlchemy model already defines — a real duplication FastAPI's own philosophy accepts as a reasonable tradeoff for its thinner-layer design. Django's ModelForm reads the single source of truth directly instead of restating it.

One View, Both GET and POST

One function handles the entire request cycle for this URL: a GET shows a blank or pre-filled form, a POST validates and saves it. A typical FastAPI/REST-style app usually splits this into two distinct endpoints instead — a genuine structural difference beyond just where routing lives (Chapter 4), extending into how the request/response cycle itself is organized.

commit=False returns the unsaved model instance the form built, without writing it to the database yet — giving a chance to set status = "active" directly in code, a field deliberately left out of the form entirely so the user never controls it, before the actual .save() happens.

The Template

Where ModelForm Stops Being the Right Tool

Chapter 5 already flagged that a full-page redirect isn't the only way this could work — a future JSON-driven version of this flow would want a fetch() call instead of a traditional form POST. ItemForm genuinely isn't suited to that: it's built to render HTML and consume form-encoded POST bodies, not to produce or consume JSON. That's specifically what Django REST Framework's own Serializers are for — JSON in, JSON out, no HTML rendering assumed. This chapter's ModelForm approach is a real, complete, working feature on its own terms, not a placeholder DRF simply replaces; Chapter 11 picks the serializer-based path for a genuinely different reason (the interactive features that need real JSON), not because this chapter's approach was wrong.

Where This Course Is Headed

Expiry alerts, item history and search, marking items used, recipe lookup, Django REST Framework — which revisits this chapter's own ModelForm-vs-serializer fork directly — deployment, and a capstone.

Hands-On Exercises

With items actually being added, this chapter builds the first payoff feature: surfacing what's about to go to waste.

The QuerySet

expiry_date__lte is Django's own field-lookup syntax — a double-underscore suffix mapping directly to a SQL comparison (__lte → <=, __gte → >=, __contains → LIKE, and so on). SQLAlchemy, Python's other major ORM, takes a genuinely different syntactic approach — operator overloading, so the identical comparison reads as Item.expiry_date <= threshold directly. Both are real, working styles for the same underlying idea; recognizing Django's own double-underscore convention on sight is worth having, since it looks unusual coming from any other ORM.

timezone.now(), Not datetime.now()

Django's modern default, USE_TZ=True, makes the project timezone-aware. Using plain datetime.now() in a timezone-aware project produces a naive datetime with no timezone attached at all — comparisons against Django's own timezone-aware stored values can then silently be wrong, especially once the deployed server and its users don't share a timezone. django.utils.timezone.now() is Django's own answer to exactly the same category of problem every Food Tracker course has hit in its own way — never trust the wrong clock.

No Composite Index Drama Here — a Genuinely Fair Point for This Course

Food Tracker (React + Firebase)'s own Chapter 7 needed an entire section on Firestore's composite-index requirement — a query combining an equality filter and a range filter on two different fields simply refuses to run at all until an index is explicitly declared. Django's ORM, running on a real relational database, has no equivalent hard requirement: the identical two-field filter here just runs. It might run slowly without an index as the table grows — ordinary SQL's own honest tradeoff, matching that same comparison the Firebase course already drew — but it never refuses outright the way Firestore does. This is one of the few places in the whole quartet where the relational side genuinely has the easier time, worth saying plainly rather than only ever finding fault with it.

The Template

{% empty %} is Django's own built-in "if the loop had nothing to iterate" branch, right inside the {% for %} tag — no separate {% if items %} wrapper needed around it.

Where This Course Is Headed

Item history and search, marking items used, recipe lookup, Django REST Framework, deployment, and a capstone.

Hands-On Exercises

Every item ever added lives in one list — active items with a real expiry date, used items without one, exactly as Chapter 2 modeled them. This chapter makes that combined history searchable in real time, and lands on a genuinely different architecture than this app's Firebase-based sibling course did.

The History View

A Thin JSON Endpoint — Deliberately Not DRF Yet

Live search genuinely needs the frontend to ask the server "what matches this text?" repeatedly, without a full page reload per keystroke — exactly the kind of interactive feature Chapter 6 flagged as DRF's own eventual territory. But standing up Django REST Framework's full machinery for one simple, read-only endpoint would be premature. This chapter takes the honest middle path: a single minimal view returning JsonResponse directly, no serializer class involved. DRF's real payoff (Chapter 11) arrives once several endpoints and genuinely richer validation actually justify it — not before.

name__icontains is a real, native, case-insensitive substring match, built directly into Django's ORM — one line, no workaround, no shadow field. safe=False is required because JsonResponse defaults to expecting a dict (a historical safeguard against a JSON-hijacking risk that applied to older browsers when a bare array was the top-level response); returning a plain list means opting out of that default explicitly.

A Genuinely Fair, Direct Contrast

Food Tracker (React + Firebase)'s own Chapter 8 needed real, honest work to get case-insensitive, substring-anywhere matching at all — Firestore has no equivalent of SQL's LIKE, so that course built a nameLower shadow field and ultimately chose client-side filtering specifically to get genuine mid-word matching. Here, on a real relational database, icontains already does exactly that, natively, in the query itself. This is a genuine SQL-side advantage worth crediting plainly, the same way Chapter 7 already credited SQL honestly for not needing a composite index.

The Frontend Genuinely Needs Debouncing This Time

This is the one place this course's own approach is more expensive per keystroke than the Firebase course's own choice, and worth being precise about why: this view hits the real database on every single request, rather than filtering an already-loaded, small array in memory. Debouncing — waiting for typing to pause before actually firing the request — genuinely matters here, unlike the Firebase course's own chosen approach, which loaded the full history once and needed no debounce at all because filtering afterward never touched the network again.

Where This Course Is Headed

Marking items used, recipe lookup, Django REST Framework — now genuinely justified by more than one interactive endpoint — deployment, and a capstone.

Hands-On Exercises

A short chapter — and a good place to see how a decision this app's Firebase-based sibling course treated very carefully turns out to need almost no ceremony at all in a relational model.

The View

get_object_or_404 is a small, genuinely useful Django shortcut — it combines the lookup and an automatic 404 response if nothing matches, instead of a manual try/except Item.DoesNotExist.

expiry_date = None: Simply the Right Answer Here

Food Tracker (React + Firebase)'s own Chapter 9 spent real effort explaining why deleteField(), not null, was the correct choice — because in Firestore's schema-on-read model, a document created used-from-the-start never had the field at all, and setting it to null on an existing document would have created a second, inconsistent representation of "no expiry." That entire problem simply doesn't exist here. Chapter 2's expiry_date column is always present, on every row, regardless of history — a used item created directly as used already has expiry_date = NULL from the very start, exactly matching what this view produces on a transition. There's only ever one shape for "no expiry" in a schema-on-write model, because every row already shares the identical set of columns.

Should This Even Be a Plain Link?

mark_used takes no user input — no form fields, nothing to fill in. It's tempting to trigger it from a simple <a href="/mark-used/<id>/"> link. Resist that: a state-changing action behind a plain GET request is a real, substantive correctness problem, not a stylistic nitpick — browser prefetching, crawlers following links, or the browser's own back/forward cache can all trigger a GET request without the user ever intending to. GET is supposed to be safe and non-mutating per HTTP's own semantics; this action should be a POST, even with no actual form fields to collect:

Where This Course Is Headed

Recipe lookup, Django REST Framework, deployment, and a capstone.

Hands-On Exercises

This chapter delivers the last named feature from Chapter 1's original spec, reusing the same integration pattern Chapter 4 already established — and running into a real, honest limitation specific to how this course's views are built.

The Same Limitation, Regardless of Framework

TheMealDB's filter-by-ingredient endpoint searches exactly one ingredient per request — this isn't a Django, FastAPI, or Firebase-specific constraint at all, it's simply a property of the external API itself, identical across all four Food Tracker courses. Every one of them has to fan out one request per expiring ingredient and merge the results afterward.

A View That Fans Out

A Real Cost of This Sequential Loop

Each requests.get() call here runs one after another, and this ordinary Django view blocks entirely until every single one finishes — five expiring ingredients means roughly five times the wait of firing them all at once. This is a genuine, honest cost specific to how this view is written: Food Tracker (FastAPI)'s own async patterns and Food Tracker (React + Firebase)'s Promise.all() both fire every ingredient lookup concurrently instead. Django does support async views (async def, since Django 3.1), but doing this properly would also require swapping the synchronous requests library for an async-compatible HTTP client — real additional complexity genuinely beyond this chapter's own scope, named honestly rather than glossed over.

Relevance Sorting — The One Place All Four Courses Converge

Sorting by len(matched_ingredients) descending surfaces recipes using the most expiring items first — directly serving Chapter 1's original point: using up as much soon-to-expire food as possible in one meal. This particular piece of logic is functionally identical across all four Food Tracker courses, each expressed in its own language's idioms — a genuine convergence point after several chapters of real, honest divergence.

Caching, Same Reasoning, a New Kind of Column

JSONField (native since Django 3.1, backed by real JSON column support in modern PostgreSQL, MySQL, and SQLite) is a genuinely interesting nuance worth naming directly: even a relational, schema-on-write framework has its own escape hatch for storing semi-structured, document-like data in a single column, when that's honestly the better fit — a list of matched-meal dictionaries here doesn't cleanly decompose into further normalized tables for this app's own modest needs. Relational and document approaches aren't a strict either/or; a real relational database can hold document-shaped data exactly where that's the more sensible choice.

Where This Course Is Headed

Django REST Framework, deployment, and a capstone.

Hands-On Exercises

Chapter 8 deliberately avoided DRF for one simple search endpoint. By now there are four genuinely JSON-shaped features — search, add-item, mark-used, recipe lookup — plus Chapter 5's own full-page-reload cost still unresolved. That's the actual threshold this chapter waits for.

Installing DRF

A Serializer Isn't a Second ModelForm

Like Chapter 6's ModelForm, ModelSerializer derives its fields directly from the same Item model — no separate schema class to duplicate. But it's built for JSON in, JSON out, with no HTML rendering assumption at all. And read_only_fields works differently from Chapter 6's own commit=False pattern: commit=False lets the view set server-controlled fields after the form validates but before saving; read_only_fields instead tells the serializer itself to include a field in output (a GET response) while silently ignoring any attempt to set it via input — a genuinely different mechanism arriving at a similarly-shaped safety outcome, not the identical technique wearing a new name.

ViewSets and Routers: The Pattern Repeats, One Level Up

One ViewSet class, registered with a router, auto-generates a full set of RESTful endpoints — list, create, retrieve, update, delete — with no individual view functions written by hand for any of them. It's Django's own "batteries included" philosophy repeating itself one level deeper, this time inside DRF specifically.

The Honest Hybrid Shape

This chapter doesn't throw away Chapters 3 through 10 and replace everything with DRF. The admin (Chapter 3) stays exactly what it was. The dashboard and history pages could keep their server-rendered templates for the parts that don't need deep interactivity, while search, add-item, mark-used, and recipe lookup can genuinely migrate to these new /api/ endpoints, called via fetch() instead of a full-page form POST or redirect. Some pages stay templates; some features become a real JSON API. This hybrid shape is the honest, common reality most substantial Django applications actually settle into — not a failure to fully commit to one philosophy.

Where This Course Is Headed

Deployment, and a capstone tying every chapter together into one complete, working app.

Hands-On Exercises

Every earlier chapter's "batteries included" moments were real. This one is where that story honestly stops covering everything.

DEBUG=False: The Single Most Important Flag

Django's development default, DEBUG=True, shows full, detailed error pages — stack traces, local variable values, even source snippets. Genuinely useful while developing; genuinely dangerous left on in production, since it hands anyone who triggers an error a real window into secrets, internal paths, and database structure. DEBUG=False swaps that for a generic error page instead — but it also activates a real requirement that trips up nearly every first-time Django deployment:

With DEBUG=False, Django refuses to serve any request at all if its Host header doesn't match something in ALLOWED_HOSTS — everything that worked perfectly with runserver locally can appear completely broken the moment DEBUG flips to False, purely because ALLOWED_HOSTS was never configured for the real domain.

SECRET_KEY: This Course's First Genuine Secret

Every external API this course has touched — Open Food Facts, TheMealDB — never needed a real secret at all. Django's own SECRET_KEY is different: it signs sessions, CSRF tokens (Chapter 6's own protection depends on it), and password-reset tokens. If it leaks, an attacker can forge valid session cookies directly. It must be loaded from an environment variable, never hardcoded or committed to source control — the one place in this entire course where an actual secret genuinely exists, and it belongs to Django itself, not to anything this app integrates with.

Static Files vs. Media Files

Static files are the app's own assets — CSS, and Chapter 5's own scan.js. Media files would be user-uploaded content (this app has none currently, but the distinction is worth knowing since it's a common point of confusion). python manage.py collectstatic gathers every app's static files into one directory for production serving — a step Django's own dev server never required, since it serves static files automatically during development without it.

Django itself explicitly does not serve static files efficiently in production. A real deployment needs either a dedicated web server (nginx) in front, or a library like WhiteNoise letting the Django app serve them itself reasonably well — a genuine decision point this chapter names rather than glosses over.

SQLite in Production: An Honest, Calibrated Note

Chapter 2 called SQLite the genuine, appropriate choice for this app, not a placeholder — and for this app's own realistically small, personal-use scope, that can remain true in production too. The honest caveat: SQLite's own file-level locking becomes a real concurrency bottleneck under genuine multi-user, high-write-volume load. If this were ever a shared, heavily-used deployment, PostgreSQL is the standard upgrade path — not because SQLite is "never production-ready" (a common overstatement), but because its real limits are concurrency-shaped, and worth knowing about honestly rather than either dismissing or overselling.

Running It For Real

Chapter 1's manage.py runserver was always explicitly a development-only server — Django's own documentation says directly not to use it in production, since it offers neither real concurrency nor production security hardening. Gunicorn (or another genuine WSGI server) is what actually serves production traffic.

Where This Course Is Headed

One chapter left: a capstone tying together this course's own thread — from Chapter 1's batteries-included framing through this chapter's own real production considerations — into one complete, working app.

Hands-On Exercises

Aisha manages this deployment day to day. Every step below is a real, working feature, each one built in a specific earlier chapter.

Chapter Attribution

Hands-On Exercises