Data Modeling in Firestore

Chapter 1 named Firestore as this course's own database, in contrast to the SQL every sibling course uses. This chapter designs the Pantry Item around it properly — and the honest answer up front is that Firestore's document model doesn't just store the same data differently, it changes what "the schema" even means.

The Relational Shape (What the Other Three Courses Use)

Food Tracker (FastAPI), Food Tracker (Django), and Food Tracker (React + Express) all model a Pantry Item as one row in a single SQL table — id, name, barcode, category, a nullable expiry_date, a status column, added_at, and a nullable used_at. The database enforces column types and nullability up front, at write time — a row that violates the schema is rejected before it's ever stored.

Firestore's Document Model

Firestore stores data as collections of documents — each document a JSON-like object whose fields can be strings, numbers, booleans, timestamps, arrays, or nested maps. Critically, Firestore itself enforces no schema at all: nothing stops one document in a collection from having fields another document in the same collection lacks entirely. This is schema-on-read rather than SQL's schema-on-write — the database doesn't validate shape at all; whatever validates it is the application code, or nothing.

For this app: one top-level items collection, one document per Pantry Item, with fields name, barcode, category, expiryDate, status, addedAt, and usedAt.

A Real Firestore Document

Notice the used item doesn't set expiryDate to null — it omits the field entirely. This is a deliberate modeling choice, not an oversight: a Firestore range query (where("expiryDate", "<", someDate)) only ever matches documents where that field actually exists and is a comparable type. A document missing the field is automatically excluded from the results — quietly and correctly — which is exactly the behavior the expiry-alerts query in Chapter 7 depends on. SQL's NULL behaves differently in comparisons (a `NULL` value in a `WHERE expiry_date < X` clause is neither true nor false, and is excluded for a different underlying reason) — the end result looks similar here, but it's worth knowing the two databases arrive at it through genuinely different mechanics.

Document IDs: Not the Barcode

A tempting shortcut is using the barcode itself as the document ID, since it's already a natural unique identifier for the product. Resist it: the same product (the same barcode) can be bought — and tracked — more than once, each purchase with its own expiry date and its own lifecycle. The document ID needs to identify one purchased instance, not one product. Let Firestore auto-generate the document ID, and store the barcode as an ordinary field instead, exactly as shown above.

Use Firestore's Timestamp Type, Not Date Strings

Firestore has a native Timestamp type specifically for dates — use it for expiryDate, addedAt, and usedAt, rather than storing an ISO date string. Range queries, sorting, and Chapter 7's own "expiring within N days" logic all rely on genuine timestamp comparison, not string comparison that happens to work for well-formatted ISO strings but isn't a real date comparison at all.

Firestore vs. SQL, Side by Side

Querying Firestore: A First Look

Where This Course Is Headed

Barcode lookup via a Cloud Function, the camera-scanning React component, direct client writes to Firestore, Security Rules as the real gatekeeper, expiry alerts built on exactly the query shown above, item history and its search limitations, marking items used, recipe lookup, Firebase Authentication, deployment, and a capstone tying every chapter together.

Hands-On Exercises