Firestore document model in GCP - Commands & Configuration

Introduction

Firestore stores data in documents, which are like small records. These documents are grouped into collections. This model helps organize and access data easily without complex tables.

When you want to store user profiles with flexible fields that can change over time.

When you need to save chat messages grouped by conversation threads.

When you want to keep product information organized by categories.

When you want to quickly retrieve data without complex joins.

When you want to scale your app with a NoSQL database that handles lots of reads and writes.

Config File - firestore.rules

firestore.rules

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

This file sets basic security rules for Firestore. It allows all reads and writes for learning purposes. In real apps, you restrict access here.

rules_version: specifies the rules syntax version.

service cloud.firestore: targets Firestore database.

match /databases/{database}/documents: applies rules to all documents.

allow read, write: if true;: allows all operations unconditionally.

Commands

This command creates a Firestore document with ID 'user123' in the 'users' collection. It stores simple user data as fields.

Terminal

gcloud firestore documents create users/user123 --data '{"name":"Alice","age":30,"email":"[e-mail]"}'

Expected Output

Created document users/user123

→

--data - Specifies the JSON data fields for the document.

This command retrieves the document 'user123' from the 'users' collection to verify its contents.

Terminal

gcloud firestore documents get users/user123

Expected Output

{

  "name": "Alice",

  "age": 30,

  "email": "[e-mail]"

}

This command updates the 'age' field of the 'user123' document to 31, showing how to change data in a document.

Terminal

gcloud firestore documents update users/user123 --data '{"age":31}'

Expected Output

Updated document users/user123

→

--data - Specifies the fields to update in the document.

This command deletes the 'user123' document from the 'users' collection, cleaning up the data.

Terminal

gcloud firestore documents delete users/user123

Expected Output

Deleted document users/user123

Key Concept

If you remember nothing else from this pattern, remember: Firestore stores data as flexible documents inside collections, making it easy to organize and access data without tables.

Common Mistakes

Trying to store deeply nested data without using subcollections or flattening fields.

Firestore documents have size limits and complex nested data can cause performance issues.

Use subcollections for related nested data or flatten fields to keep documents small.

Using the same document ID for different data types in the same collection.

This can cause data overwrites and confusion when reading documents.

Use unique document IDs per data type or separate collections for different data.

Not setting Firestore security rules and leaving open access in production.

This exposes your data to anyone and risks data loss or leaks.

Write and test security rules that restrict access based on user identity and roles.

Summary

Create Firestore documents with JSON data fields inside collections.

Retrieve documents to check stored data.

Update specific fields in documents without overwriting all data.

Delete documents to remove data when no longer needed.

Practice

1. What is the basic unit of data storage in Firestore?

easy

A. A table

B. A document

C. A bucket

D. A file

Solution

1. Step 1: Understand Firestore data structure

   Firestore organizes data into collections and documents, not tables or files.

2. Step 2: Identify the smallest data unit

   The smallest unit is a document, which holds fields and values.

3. Final Answer:

   A document -> Option B

4. Quick Check:

   Firestore stores data as documents [OK]

Hint: Remember: Firestore uses documents, not tables or files [OK]

Common Mistakes:

• Confusing documents with tables from SQL databases
• Thinking Firestore stores files like Cloud Storage
• Assuming buckets are data units in Firestore

2. Which of the following is the correct way to represent a Firestore document field in JSON-like syntax?

easy

A. "name": "Alice"

B. "name" = "Alice"

C. name: Alice

D. 'name' -> 'Alice'

Solution

1. Step 1: Recall JSON field syntax

   JSON uses double quotes for keys and string values, separated by a colon.

2. Step 2: Match Firestore document field style

   Firestore documents resemble JSON, so the correct syntax is "key": "value".

3. Final Answer:

   "name": "Alice" -> Option A

4. Quick Check:

   Firestore fields use JSON syntax [OK]

Hint: Use colon and double quotes for Firestore fields [OK]

Common Mistakes:

• Using equals sign instead of colon
• Omitting quotes around keys or values
• Using arrow notation which is invalid

3. Given a Firestore collection 'users' with documents having fields {"age": 30, "active": true}, what will the query return if you filter for documents where active == false?

medium

A. All documents with active false

B. All documents regardless of active field

C. Error due to invalid filter

D. No documents

Solution

1. Step 1: Understand the data and filter condition

   Documents have "active": true, but the query filters for active == false.

2. Step 2: Evaluate query result

   No documents match active == false, so the query returns no results.

3. Final Answer:

   No documents -> Option D

4. Quick Check:

   Filter matches no documents [OK]

Hint: Filter matches only exact values; no match means empty result [OK]

Common Mistakes:

• Assuming query returns all documents
• Expecting an error for valid filter
• Confusing true and false values

4. You try to add a document with this data: {name: "Bob", age: "twenty"}. What is the likely issue?

medium

A. Firestore requires age to be a number, not a string

B. No issue, document will be added

C. Field names must be in quotes

D. Document ID is missing

Solution

1. Step 1: Check field name syntax

   Firestore expects field names as strings in JSON, so keys must be quoted.

2. Step 2: Analyze the given data

   Keys are unquoted (name, age), which is invalid JSON syntax for Firestore.

3. Final Answer:

   Field names must be in quotes -> Option C

4. Quick Check:

   Field names need quotes in Firestore JSON [OK]

Hint: Always quote field names in Firestore documents [OK]

Common Mistakes:

• Thinking Firestore auto-corrects missing quotes
• Assuming string values for numbers cause errors
• Believing document ID is mandatory in data

5. You want to model a blog app in Firestore. Each blog post has multiple comments. Which is the best Firestore document model to organize this data?

hard

A. Create a 'posts' collection with documents for each post, and a subcollection 'comments' inside each post document

B. Store all comments as an array field inside each blog post document

C. Create a single collection 'comments' with a field referencing the post ID

D. Store all posts and comments in one flat collection

Solution

1. Step 1: Consider Firestore best practices for related data

   Large or growing lists like comments should be in subcollections, not arrays, for scalability.

2. Step 2: Evaluate options for organizing posts and comments

   Using a 'posts' collection with 'comments' subcollections keeps data organized and efficient.

3. Final Answer:

   Create a 'posts' collection with documents for each post, and a subcollection 'comments' inside each post document -> Option A

4. Quick Check:

   Use subcollections for related many items [OK]

Hint: Use subcollections for many related items, not arrays [OK]

Common Mistakes:

• Putting all comments in one array causing size limits
• Using a flat collection losing post-comment grouping
• Referencing post ID without subcollections complicates queries