Project Overview & FastAPI Project Setup

Food Tracker (FastAPI)

Chapter 1 · Project Overview & FastAPI Project Setup

This is the fourth and final course in a deliberate quartet — Food Tracker (Django), Food Tracker (React + Express), and Food Tracker (React + Firebase) are its siblings, each building the exact same app in a genuinely different architecture. This course closes the set with the one variant that isn't paired with React at all: a plain, framework-free vanilla-JS frontend, keeping every chapter's attention on FastAPI and its backend itself.

What the App Actually Does

Before any architecture talk, 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, so re-adding something you've bought before is fast.
  • 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.

Why Vanilla JS, Not a Fourth React Course

Both React + Express and React + Firebase already exist in this quartet, each demonstrating React against a genuinely different backend. Pairing FastAPI with React a third time would mostly repeat frontend lessons this quartet has already taught twice over, diluting the actual point of this course: FastAPI's own backend design. A deliberately plain frontend — real HTML, real CSS, real fetch calls, no build step, no framework — keeps every chapter's focus exactly where it belongs.

Why FastAPI

Three concrete, genuine reasons, not just general popularity:

  • Async-native from the ground up. Route handlers are written as async def by default, with real, non-blocking I/O for API calls and database access — a different default than Django's own synchronous-first model.
  • Pydantic built in. Request and response shapes are declared as real Python classes with real type hints, validated automatically on every request — no separate serializer library to reach for.
  • Automatic interactive API documentation. A fully working, browsable API explorer at /docs, generated entirely from the route definitions and Pydantic models already written for validation — nothing extra to configure.
A real feature none of the other three courses get for free
Food Tracker (Django) would need Django REST Framework plus an add-on like drf-spectacular to get interactive API docs at all. Food Tracker (React + Express) has nothing built in for this — a tool like Swagger UI would need to be wired up manually, describing every route by hand. Food Tracker (React + Firebase)'s own Cloud Functions have no request/response schema tooling whatsoever. FastAPI's own /docs page is genuinely automatic, generated directly from the same Pydantic models Chapter 2 writes for validation — one more course-specific "batteries included" moment, the same shape as Django's own free admin panel, just for a completely different battery.

Reusing an Already-Established Project Structure

This site's own Website Rebuild with FastAPI course already worked out a real, proven FastAPI project layout — this course reuses that convention rather than inventing a new one:

food-tracker-fastapi/ ├── main.py # FastAPI app instance, route registration ├── models.py # SQLAlchemy models (Chapter 2) ├── schemas.py # Pydantic models (Chapter 2) ├── database.py # SQLAlchemy engine/session setup ├── routers/ │ ├── items.py │ ├── lookup.py │ └── recipes.py ├── static/ # the plain vanilla-JS frontend │ ├── index.html │ ├── app.js │ └── style.css └── requirements.txt

Installing and Running

python -m venv venv source venv/bin/activate # venv\Scripts\activate on Windows pip install fastapi uvicorn[standard] sqlalchemy python-dotenv uvicorn main:app --reload

A minimal main.py, confirming the setup works end to end before any real feature exists:

# main.py from fastapi import FastAPI from fastapi.staticfiles import StaticFiles app = FastAPI(title="Food Tracker") @app.get("/api/health") async def health(): return {"status": "ok"} app.mount("/", StaticFiles(directory="static", html=True), name="static")

StaticFiles(..., html=True) serves index.html automatically for the root path and any unmatched path — this course's own equivalent of the SPA-fallback route Food Tracker (React + Express) had to hand-write, given for free by a single constructor argument here, since there's no client-side router involved at all in a plain multi-page vanilla-JS app.

FastAPI itself is deliberately minimal
Unlike Django's own batteries-included model, FastAPI ships no ORM, no admin panel, and no built-in database layer at all — SQLAlchemy (Chapter 2), a real database driver, and every other piece are choices this course makes and assembles deliberately, not defaults FastAPI provides out of the box. FastAPI's own "batteries included" story is narrower and more specific: async request handling, validation, and documentation — genuinely excellent at exactly those three things, and honestly minimal everywhere else.
Visit /docs immediately, before writing a single frontend line
Once uvicorn main:app --reload is running, http://localhost:8000/docs already shows a working, interactive explorer for the /api/health route above — a genuinely useful way to test every route this course builds, directly in the browser, without needing the vanilla-JS frontend at all.

Where This Course Is Headed

Data modeling with Pydantic and SQLAlchemy next — two genuinely separate layers, one for request/response validation and one for the database — then barcode lookup, camera scanning, the add-item flow, expiry alerts, item history and search, marking items used, recipe lookup, async patterns and background tasks, deployment, and a capstone tying every chapter into one complete, working app.

Hands-On Exercises

Exercise 1

Explain why this course deliberately uses a plain vanilla-JS frontend instead of pairing FastAPI with React a third time in this quartet.

📄 View solution
Exercise 2

Explain why FastAPI's automatic /docs page is described as a genuine feature none of the other three sibling courses get for free, naming what each sibling would need instead.

📄 View solution
Exercise 3

Explain why StaticFiles(directory="static", html=True) is described as this course's own equivalent of Food Tracker (React + Express)'s own hand-written SPA-fallback route, and why main.py above still registers the /api/health route before mounting it — despite this course having no client-side router to worry about.

📄 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
  • Frontend: deliberately plain vanilla JS — no framework, no build step, keeping focus on FastAPI itself
  • Why FastAPI: async-native, Pydantic validation built in, automatic interactive docs at /docs
  • Real advantage: /docs is genuinely automatic — none of the three sibling courses get this for free
  • Honest limit: FastAPI itself ships no ORM, no admin, no database layer — assembled deliberately, not provided by default
  • Project structure: reused from Website Rebuild with FastAPI's own established convention
  • Next chapter: Data Modeling with Pydantic & SQLAlchemy