Project Overview & Firebase Setup

This is the fourth and last of four courses building the exact same personal cataloguing tool in four genuinely different architectures — Personal Catalogue (PHP & MySQL), Personal Catalogue (Django & PostgreSQL), and Personal Catalogue (React, Express & MongoDB) are all already complete. That third sibling already made the case for a document database over a rigid relational schema; this course takes the same underlying idea — genuinely differently-shaped item records — and answers it with a managed document database instead of a self-run one, so the two can be read side by side as self-managed vs. managed NoSQL.

What the App Actually Does

The shared spec every course in the quartet builds toward, unchanged from the other three:

• Catalogue four kinds of item — books, CDs, DVDs, and Blu-rays — so it's possible to quickly check "do I already own this CD?" or "what Python books do I have?"
• Tag books with free-form labels (a FastAPI book might get Python, Web Development, Programming, Web Frameworks) so related books can be found by topic later.
• Add items manually for the first release — title, author/artist, format-specific details, tags where relevant.
• Search and browse the collection to answer the "do I have this?" question quickly.

Barcode scanning is explicitly out of scope for this first release — a real, obvious way to add items faster, but deliberately deferred rather than allowed to hold up a release that needs to ship quickly. This is a genuinely personal, single-user tool — nothing in this spec, or in any of its three completed siblings, calls for real user accounts, so this course doesn't build any either.

Why Firestore for This One

The MongoDB sibling's own real argument still holds here: a book's fields (author, ISBN, publisher) and a DVD's fields (director, runtime, disc format) genuinely don't overlap much beyond title and year, so forcing all four item types into one rigid, shared shape either wastes a lot of null columns or splits into several tables that need joining back together for any "show me everything" view. Firestore, Firebase's own document database, gives the identical genuine flexibility — a single items collection can hold a book document and a DVD document side by side, each with only the fields that item type actually needs.

Where the two variants genuinely diverge is what happens after that flexibility is granted. The MongoDB sibling's own Chapter 2 built real, per-type schema validation on top of its flexible collection using Mongoose discriminators — a document that doesn't match its declared item type's schema is rejected before it ever reaches the database. Firestore has no built-in equivalent to that at all: any document, in any shape, can be written to any collection, and Firestore itself will never object. Whatever validation this course ends up wanting has to come from somewhere else — Chapter 2 goes deep on exactly what "somewhere else" means once real code is being written against it.

Where Does the Backend Actually Live?

The MongoDB sibling needed a real Express server regardless — MongoDB isn't reachable directly from a browser, so some backend process was always going to exist to hold the connection and expose CRUD routes. Firestore removes that requirement outright: its official client SDK can read and write documents directly from React, with no server of this course's own in between at all. That's a genuine architectural fork worth naming honestly now rather than assuming an answer — direct client-to-Firestore access is faster to build but puts more weight on Firestore's own Security Rules to do the job an Express route's own validation code would otherwise do; a small backend API layer keeps that validation in familiar, testable code at the cost of reintroducing the very server this variant doesn't strictly need. Chapter 3 resolves this for real rather than leaving it open for the rest of the course.

A Real Deadline, Not Just a Framing Device

This project genuinely needs a working first release quickly, exactly as its three completed siblings each describe. That constraint shapes real decisions here too: a plain add-item form before any real polish, and — a genuine, welcome side effect of picking Firebase specifically — no server of this course's own to write, configure, and keep running, which is itself real time saved against every one of its three siblings. Chapter 8 covers where the remaining corners were deliberately cut given that time pressure.

Setting Up a Firebase Project

Create a project at the Firebase console, then enable Firestore in production mode — not test mode, which allows unrestricted reads and writes and would leave real validation entirely unaddressed from day one. With the project created, bring the Firebase SDK into the React app:

Where This Course Is Headed

Data modeling in Firestore, held up directly against the MongoDB sibling's own schema (Chapter 2); resolving the client-SDK-vs-backend-API question raised above for real (Chapter 3); one React form handling several genuinely different item shapes (Chapter 4); tags — attaching, managing, and filtering by tag on books (Chapter 5); search, and Firestore's own real, honest query limitations compared with MongoDB's richer query language (Chapter 6); the list and detail views in React (Chapter 7); fast manual entry given the project's own real deadline (Chapter 8); deployment via Firebase Hosting (Chapter 9); and a capstone integrating this catalogue into the existing Astro-based site, closing with a direct, final comparison of self-managed MongoDB against managed Firestore across the whole project (Chapter 10).

Hands-On Exercises