Project Overview & Django Project/App Setup

Food Tracker (Django)

Chapter 1 · Project Overview & Django Project/App Setup

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

django-admin startproject foodtracker .
python manage.py startapp pantry

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

# settings.py
INSTALLED_APPS = [
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
    "pantry",  # the new app, added by hand
]

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.sqlite3",
        "NAME": BASE_DIR / "db.sqlite3",
    }
}

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.

python manage.py runserver

A working admin panel, before writing any business logic at all

Once pantry's models exist (Chapter 2), Django's admin site gives a genuine, working CRUD interface for them for free, with zero custom code — something FastAPI has no equivalent of at all without building it by hand. This is the "batteries included" philosophy made concrete: an entire category of work Django considers part of the framework itself, that a thin-API-layer framework considers entirely the developer's own problem.

Name apps after the domain, not generically

pantry reads clearly everywhere Django references app names — INSTALLED_APPS, migration folders, template lookup paths. A generic name like app1 would work identically but read as meaningless the moment the project has more than one app.

Forgetting INSTALLED_APPS is the classic first Django mistake

A new app's models won't be picked up by migrations, and its templates or static files won't be found, until it's added to INSTALLED_APPS — and the resulting errors are often confusing rather than direct: a "template does not exist" error, for instance, rather than a clear "app not registered" message. If something Django-related seems to silently not exist, checking INSTALLED_APPS first is worth making a reflex.

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

Exercise 1

Explain what Django's "View" actually corresponds to in classic MVC terms, and why this chapter calls it a common point of confusion for newcomers.

📄 View solution

Exercise 2

Explain the difference between a Django project and a Django app, using this chapter's own startproject/startapp commands as your example.

📄 View solution

Exercise 3

Explain what breaks if a newly created app is never added to INSTALLED_APPS, and why the resulting error can be confusing to diagnose.

📄 View solution

Chapter 1 Quick Reference

The shared app — barcode scan (Open Food Facts) → expiry tracking → alerts → searchable history → recipe lookup (TheMealDB); no meal planner
Batteries included — ORM, admin, templating, forms, auth all ship together, unlike FastAPI's thin-layer approach
Project vs. app — foodtracker (config) vs. pantry (the feature itself)
MVT — Model (ORM), View (actually the controller), Template (presentation) — not classic MVC naming
SQLite — a genuine, appropriate choice for this personal, single-user app
This course's own throughline: one integrated framework deciding more up front, vs. FastAPI's compose-it-yourself approach
Next chapter: Data Modeling with Django's ORM