Personal Catalogue: React & Firebase — Chapter 2, Exercise 3
=====================================================================

TASK
Explain, in your own words, why calling `validateItem()` from
application code is a real safeguard but not the same guarantee
Mongoose discriminators give — and name the one Firestore-native
mechanism that could close that remaining gap.

SOLUTION

Mongoose's own discriminator schemas are enforced by Mongoose itself,
sitting directly between any calling code and the MongoDB driver — no
matter which part of the codebase tries to write a Cd document with no
`artist`, that write goes through the same schema check and gets
rejected the same way, every time, automatically.

`validateItem()` gives real protection, but only for code paths that
actually remember to call it. It is a plain JavaScript function with no
special relationship to Firestore at all — if a new form component, a
one-off admin script, or a future teammate writes directly to the
`items` collection via `addDoc()` without calling `validateItem()`
first, Firestore will accept whatever gets sent, malformed or not,
exactly as if the validator never existed. The guarantee only holds as
strongly as the discipline of every caller remembering to use it.

The one Firestore-native mechanism that can close this gap for real is
Firestore Security Rules. Rules are evaluated by Firebase's own servers
for every single read and write request, regardless of which client, script,
or code path sent it — the same universal enforcement Mongoose
discriminators provide, just expressed as declarative rules instead of
JavaScript schema classes. A rule can check that `request.resource.data`
actually contains a `title`, that an `itemType` of `"Book"` is
accompanied by an `author`, and reject the write at the database layer
itself if it isn't — the real difference being that this check would
apply universally, the way Mongoose's does, rather than only to
whichever code paths remembered to call a function first.

WHY THIS WORKS AS AN ANSWER
----------------------------
It correctly locates the real gap (validation tied to a specific
function call vs. validation enforced by the database layer itself
regardless of caller), doesn't overstate `validateItem()`'s own real
value, and names the specific, real mechanism — Security Rules — that
would actually close the gap, rather than a vague "add more checks"
answer.