Capstone: A Complete, Working Food Tracker

Before touching the frontend at all, Priya's own developer opens /docs to confirm the deployment is healthy — Chapter 1's own praised automatic API explorer, still available in this deployment since it was left enabled deliberately, per Chapter 11's own decision.

Priya scans the barcode. Chapter 4's plain-function startScanner decodes it client-side, calling Chapter 3's genuinely async lookup route — httpx.AsyncClient checking BarcodeCache first, falling back to a live Open Food Facts call, with the event loop free to serve other requests the whole time it waits.

The add-item view pre-fills from that lookup. Priya sets the expiry date and submits; Chapter 5's ItemCreate schema validates the request before create_item's own body ever runs — no hand-written checks anywhere in that route, because there's nothing left to check by the time it executes.

Chapter 6's alerts route surfaces the eggs once they're within three days of expiring — a real typed Date column comparison, correct regardless of formatting, and a plain def since a local SQLite query never needed async in the first place.

Priya searches "egg." Chapter 7's ilike() finds it instantly — no shadow field, the same real advantage Django and Express both claim in their own courses.

The eggs get used up. Chapter 8's PATCH /{item_id}/use clears expiry_date and guards against a duplicate click, then Chapter 10's BackgroundTasks schedules a UsageLog entry — written after the response is already back in Priya's browser, using its own dedicated session since the request's own is already closed by then.

The same markUsed function calls loadAlerts() and loadRecipeSuggestions() directly, by name — Chapter 8's own honest point still holds: this app never needed anything like the Express sibling's own Context, because there's no component tree creating that coordination problem in the first place.

With chicken and spinach both nearing expiry, Chapter 9's asyncio.gather() fans out to TheMealDB concurrently — each lookup_ingredient call opening its own dedicated session, genuinely safe under concurrency, unlike the bug that pattern was specifically designed to avoid — ranked by how many expiring ingredients each recipe actually uses.

Priya's whole session runs against a real deployment: gunicorn managing several Uvicorn workers, no CORS configuration anywhere since the frontend has shared FastAPI's own origin since Chapter 1, worker count kept modest specifically to avoid the SQLite lock contention Chapter 11 named honestly, and nginx terminating HTTPS in front of it all.