So I have a pretty simple use-case:

I have a simple app with questions (stored in firestore), and I want users to be able to filter on the questions before they start an exercise.

Right now it's just 100 questions, (but could eventually grow to 1000+) Some days I have 100+ users, (but could eventually grow to 1000+)

To filter the questions I get all questions from firestore:

const fetchAllQuestions = async (): Promise<Question[]> => {
  const q = query(collection(fireStore, "questions"));
  const querySnapshot = await getDocs(q);
  const questions: any = [];
  querySnapshot.forEach((doc) => questions.push(doc.data()));
  return questions as Question[];
};

and then I apply the filter.

But this is one document-read per user and question so 100 questions and 100 users becomes 10000 document reads, eating up the quota in just 5 days. And that is a best case scenario without any page-reloads or cache-invalidations.

And even less viable if the page grows in content and usage.

Since "filtering on just a subset of questions" isn't an option I see some ways of bypassing this:

a) Caching the result in local-storage, this would cover page reloads and return visitors but I'd need to invalidate the storage-key when updating the questions, and I'd still reach the quote after 500 unique visitors.

Plus, it feels like a "hack".

b) Just put ALL the questions in one single document, or chop them up and have 100 per document or something similar. This would basically solve the problem since I'm not fetching single questions anyway. Uploading questions would be slightly more cumbersome since I need to fetch the whole bunch, then update the question and then upload the whole lot as one big document.

Still, it also feels slightly like a "hack".

So I can't help but feel like there's something I'm missing here, some "idiomatic" firestore-way of handling this use case that I must have missed?