Should I create a duplicate collection/document for each use-case? (Firebase/Firestore)-CodePudding

I'm trying to build an ecommerce app with firebase on the backend. I have a collection of 1000 products, each of which is stored as a separate document, which have product specific info such as price, title etc.

document:{
  title: 'Some Title',
  price: '$99.99',
  genres: ['Horror', 'Action']
}

So in my app I need to display these products in many places, such as product carousels(similar to a bookshelf with arrow buttons at the ends), and also in a search results page. At any given page, I assume that I will need to display at least 50 products, either as search results, or multiple carousels. I understand that I can use queries to get this data from firebase. But since each document I retrieve counts as (at least)one firestore read, I assume that a typical user session would run into 100 reads, if not thousands.

It seems a little inefficient to me that I need to read multiple documents to get this data, when I could just all that data in a single array, as its own document. That would mean I get charged for one document read, not 50, per page.

Is this how it is expected to be done? Should I create a new document containing the data I need for each specific use case?

P.S. I'm pretty new to backend dev, let alone firebase.

CodePudding user response：

TL;DR Yes, you should create a new document with the needed data for each specific use case, but it’s not recommended to make it as a document with nested objects like arrays with 1000 elements.

From a technical point of view, Cloud Firestore is optimized for storing large collections of small documents.

Depending on the use case, you can select the most appropriate Cloud Firestore data structure.

For example, the 10 most buyed books of the month can be a document with nested complex objects like arrays or maps. This structure could be useful for use cases with a small or predefined number of elements, but as stated here, if your data expands over time with larger or growing lists, the document also grows, which can lead to slower document retrieval times.

In plus thousand registers, a better choice can be structure your data as subcollections. It is, you can create collections within documents when you have data that might expand over time, with the main advantage that, as your lists grow, the size of the parent document doesn't change.

Cloud Firestore also has several features to help you manage queries that return a large number of results:

Cursors, which allow you to resume a long-running query.
Page tokens, which help you paginate the query results.
Limits, which specify how many results to retrieve.
Offsets, which allow you to skip a fixed number of documents.

There are no additional costs for using cursors, page tokens, and limits. In fact, these features can help you save money by reading only the documents that you actually need.

As a best practice, do not use offsets. Instead, use cursors. Using an offset only avoids returning the skipped documents to your application, but these documents are still retrieved internally. The skipped documents affect the latency of the query, and your application is billed for the read operations required to retrieve them.