Data Modeling

Chapter 1 promised two things for this chapter: the real Firestore document shapes, built to sit side by side with the MongoDB sibling's own schema for direct comparison, and a real answer to the validation gap that comparison exposed. This chapter delivers both — though not every piece of the second one lands here; where the resulting validation actually gets called from is still an open architectural question, resolved for real in Chapter 3.

What the MongoDB Sibling Built

Personal Catalogue (React, Express & MongoDB)'s own Chapter 2 built a base Item schema (title, releaseYear, notes) and four Mongoose discriminators — Book, Cd, Dvd, Bluray — each adding real, type-specific fields on top of that shared base, all writing into one physical items collection distinguished by a stored itemType field. Every discriminator schema still enforces its own required fields at write time: a Cd document with no artist is rejected by Mongoose before MongoDB ever sees it.

This chapter builds the same real shapes — the same field names, the same required fields, even the same itemType field name — in Firestore. What Firestore can't reuse is the enforcement mechanism itself: there is no Firestore equivalent of Item.discriminator(). A Firestore collection has no declared shape at all, for any document, ever.

The Same Shapes, No Enforcement

Firestore's own flat document model actually makes reproducing the shapes easy — a document can hold any fields, so the base fields and a given item type's own fields just sit together directly on one document, with no separate base-versus-subtype schema objects needed at all:

Both documents land in the same items collection, side by side, exactly as the MongoDB sibling's own discriminators arrange things — but nothing about that addDoc call checked that a Cd document actually needs an artist, or that itemType is even one of the four real values this app understands. A typo — itemType: "CD", capitalized differently from every other document — would be accepted by Firestore exactly as readily as a correctly-typed one.

Field for field, this is the identical shape the MongoDB sibling settled on. The diagram above could be relabeled "MongoDB" and nothing in it would need to change — the real divergence between the two courses isn't in what gets stored, it's in what happens the instant before storage.

Closing the Validation Gap: a Real Shape Validator

Chapter 1 left this open rather than asserting an answer. Here's the answer, at least at the "what should be checked" layer: a small, standalone function that knows this app's own real rules — which fields each item type requires, and which fields have a restricted set of valid values, the direct equivalent of Mongoose's own required: true and enum options:

Run against the two documents above, plus two deliberately broken ones:

That's the exact same class of rejection the MongoDB sibling's own discriminators give for free — a Cd with no artist never reaches storage — reproduced by hand in plain JavaScript, because Firestore itself will never reject it on its own.

One Real Advantage Firestore Gets for Free

The MongoDB sibling's own Chapter 2 flagged a genuine limitation worth revisiting here: a document fetched through the base Item model doesn't expose author, artist, or any other discriminator-specific field, even though the field is really there in the underlying MongoDB document — Mongoose only attaches those extra fields when a document is loaded through its own matching discriminator model.

Firestore has no equivalent problem, for a simple reason: it has no separate base-model and subtype-model objects at all. Every document fetched from the items collection comes back as a plain object carrying every field it was actually written with:

Hands-On Exercises