Exercise 3: The Schema-on-Read Trade-Off — Possible Solution
====================================================================

THE COST FIRESTORE PUSHES ONTO THE APPLICATION
------------------------------
Per this chapter, SQL's schema-on-write enforces column types and shape at the moment data is written - the database itself rejects a row that doesn't match the schema, before it's ever stored. Firestore's schema-on-read approach enforces nothing at write time: nothing stops a typo'd field name (expiryDate vs expiry_date, as the chapter's own warn-box describes) from silently creating a second, unintended field with no error at all. The cost of catching that kind of inconsistency shifts entirely from the database onto the application's own code - and if the application doesn't do that checking itself, nothing else will.

HOW THE SHARED-INTERFACE SUGGESTION PARTIALLY ADDRESSES IT
------------------------------
Defining a single TypeScript interface (or at minimum a shared constants file) for the Item document shape, and using it at every write site in the app, gives back some of that lost safety voluntarily - a typo in a field name would then be caught by TypeScript's own type checking at compile time, rather than silently succeeding at runtime the way an unstructured write would. It's only a partial fix because it's entirely optional and unenforced by Firestore itself - nothing stops a future change, or a different developer, from writing to the collection without going through that shared interface at all.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies that schema-on-read shifts consistency enforcement from the database onto the application's own code, uses the chapter's own field-name-typo example to illustrate the risk concretely, and explains that the shared-interface approach only partially compensates because it's voluntary rather than enforced by Firestore itself.