Exercise 2: Why Firebase Needed Security Rules, and This Course Didn't — Possible Solution
====================================================================

WHY FIREBASE NEEDED SECURITY RULES
------------------------------
In Food Tracker (React + Firebase), the React client writes directly to Firestore - there is no server process the client's write request passes through on its way to the database at all. Without Security Rules deliberately configured, nothing would validate or restrict what a client could write; Security Rules had to be added specifically to fill that otherwise-empty gap between the client and the database.

WHY THIS COURSE'S EXPRESS ROUTE ALREADY PROVIDES THAT "BY CONSTRUCTION"
------------------------------
In this course's own architecture, the React client can never write to the SQLite database directly at all - the database connection only exists inside the Express process, and the only way any data reaches it is by going through a route like POST /api/items. Because that route already runs real JavaScript code before touching the database, adding validation there isn't introducing a new layer that didn't exist before - it's simply writing code inside a gate that the architecture already forced every write to pass through.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that Firebase's direct-write model has no server code in the path by default, requiring Security Rules to be deliberately added as a new enforcement layer, and correctly explains that this course's own architecture already routes every write through server code, making validation a natural extension of an existing gate rather than a new one.