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

TASK
Using this chapter's own scorecard, pick the single real finding from
the whole course you think matters most for a genuinely larger
catalogue (tens of thousands of items rather than a few hundred), and
explain why — citing the specific chapter it came from.

SOLUTION

The finding that matters most at that scale is the search limitation
from Chapter 6: this course has no real substring/text-search
capability of any kind, and the practical workaround — fetching every
document in the collection and filtering client-side with
.toLowerCase().includes() — was explicitly built and justified only
for "a few hundred to a few thousand items," matching the MongoDB
sibling's own honest scale note for its full-collection regex scan.

At tens of thousands of items, this specific approach breaks down in
two real, connected ways. First, cost: Chapter 6 already established
that Firestore bills per document read, and searchItems() reads the
entire collection on every call regardless of the search term — at
10,000+ documents, even with Chapter 8's own debounce reducing how
often it fires, a single genuine search session could plausibly cost
tens of thousands of billed reads. Second, latency: downloading and
filtering an entire large collection client-side, on every search,
would produce a visibly slow, unresponsive search experience long
before it produces an outright error — a real usability failure, not
just a cost one.

None of the other scorecard items scale this badly. The lack of
per-type schema enforcement (Chapter 2) and the manual security-rules
work (Chapters 3 and 5) are one-time costs paid regardless of
collection size, not costs that grow with it. The deployment
simplification (Chapter 9) and the eliminated sync-wiring (Chapter 7)
both stay genuine wins at any scale. Search is the one area where the
real workaround this course settled on is explicitly, honestly scoped
to a size this app is expected to stay within — and a genuinely larger
catalogue would need to replace it with a real third-party search
service, exactly the ceiling Chapter 6's own quick reference already
named.

WHY THIS WORKS AS AN ANSWER
----------------------------
It picks a specific, real finding rather than a vague "Firestore has
tradeoffs" answer, ties the reasoning to the actual mechanism
(full-collection reads plus client-side filtering) rather than a
general scalability claim, and explains concretely why this
particular finding degrades with scale while contrasting it against
other scorecard items that genuinely don't.