Data modeling best practices in Firebase - Commands & Configuration

Introduction

Data modeling in Firebase helps organize your app's data so it is easy to find and update. Good data models prevent slow app performance and complicated code.

When you want to store user profiles and their posts separately but linked.

When you need to quickly get a list of items without loading unnecessary details.

When you want to avoid repeating the same data in many places to save space.

When you want to update data in one place and have it reflect everywhere.

When you want your app to scale smoothly as more users join.

Config File - firestore.rules

firestore.rules

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
    match /posts/{postId} {
      allow read: if true;
      allow write: if request.auth != null && request.auth.uid == request.resource.data.authorId;
    }
  }
}

This file sets security rules for Firestore data access.

The /users/{userId} path allows only the logged-in user to read and write their own profile.

The /posts/{postId} path allows anyone to read posts but only the author can write or update their posts.

Commands

This command initializes Firestore in your Firebase project, setting up necessary files and configuration.

Terminal

firebase init firestore

Expected Output

=== Firestore Setup ===

✔ Firestore rules file created at firestore.rules

✔ Firestore indexes file created at firestore.indexes.json

Firebase initialization complete.

→

--project - Specify the Firebase project to initialize Firestore for

This command deploys your Firestore rules and indexes to the Firebase project, making your data model rules active.

Terminal

firebase deploy --only firestore

Expected Output

=== Deploying to 'my-firebase-project'...

✔  firestore.rules: Firestore rules deployed successfully

✔  firestore.indexes.json: Firestore indexes deployed successfully

✔  Deploy complete!

→

--only - Deploy only Firestore related configuration

This command lists the current Firestore indexes, helping you verify your data model supports efficient queries.

Terminal

firebase firestore:indexes

Expected Output

Current Firestore indexes:

Collection Group: posts

  Fields:

    authorId Ascending

    createdAt Descending

  State: READY

Key Concept

If you remember nothing else from this pattern, remember: organize your data to avoid duplication and enable fast queries by structuring collections and documents thoughtfully.

Common Mistakes

Storing all data in one big document instead of splitting into collections and documents.

This causes slow reads and writes because Firestore loads entire documents even if you need only part of the data.

Split data into smaller documents and collections to load only what you need.

Duplicating data in many places without a plan.

It makes updates complicated and can cause inconsistent data if one copy is changed but others are not.

Use references or IDs to link data instead of copying it.

Not setting proper security rules for data access.

Anyone could read or write data they shouldn't, risking privacy and data integrity.

Write rules that check user identity and limit access accordingly.

Summary

Initialize Firestore with firebase init firestore to set up your data model files.

Deploy your Firestore rules and indexes with firebase deploy --only firestore to enforce data access and optimize queries.

Check your Firestore indexes with firebase firestore:indexes to ensure your data model supports efficient queries.

Practice

1. What is the main reason to use collections and documents in Firestore for data modeling?

easy

A. To make data read-only for all users

B. To store all data in one big JSON object

C. To avoid using any security rules

D. To organize data in a way that is easy to query and scale

Solution

1. Step 1: Understand Firestore structure

   Firestore organizes data into collections and documents to keep data structured and easy to access.

2. Step 2: Benefits of collections and documents

   This structure allows efficient queries and scaling as your app grows.

3. Final Answer:

   To organize data in a way that is easy to query and scale -> Option D

4. Quick Check:

   Firestore uses collections/documents for scalable data [OK]

Hint: Think of collections as folders and documents as files [OK]

Common Mistakes:

• Thinking all data should be in one JSON object
• Ignoring the need for security rules
• Assuming data is read-only by default

2. Which of the following is the correct way to reference a document in Firestore?

easy

A. db.users('user123')

B. db.collection('users').doc('user123')

C. db.get('users/user123')

D. db.document('users').collection('user123')

Solution

1. Step 1: Recall Firestore syntax

   Firestore uses collection() to select a collection and doc() to select a document.

2. Step 2: Check each option

   db.collection('users').doc('user123') correctly uses collection('users').doc('user123'). Others do not follow Firestore syntax.

3. Final Answer:

   db.collection('users').doc('user123') -> Option B

4. Quick Check:

   Firestore document reference uses collection().doc() [OK]

Hint: Remember: collection() then doc() for Firestore paths [OK]

Common Mistakes:

• Using incorrect method names like get() or document()
• Swapping collection and document order
• Trying to access documents directly from db without collection

3. Given this Firestore data model:

users (collection)
  user123 (document)
    name: 'Alice'
    posts (collection)
      post1 (document)
        title: 'Hello'

What will db.collection('users').doc('user123').collection('posts').get() return?

medium

A. A list of all posts documents under user123

B. An error because posts is not a field

C. Only the user123 document data

D. All users documents with their posts

Solution

1. Step 1: Understand nested collections

   In Firestore, collections can be nested under documents. Here, posts is a subcollection under user123.

2. Step 2: What does the query do?

   The query gets all documents in the posts collection under user123, so it returns all posts documents.

3. Final Answer:

   A list of all posts documents under user123 -> Option A

4. Quick Check:

   Subcollections return their documents on get() [OK]

Hint: Subcollections are accessed by chaining collection().doc().collection() [OK]

Common Mistakes:

• Thinking subcollections are fields inside documents
• Expecting get() to return parent document data
• Assuming get() returns all users and posts together

4. You have this Firestore security rule snippet:

match /users/{userId} {
  allow read, write: if request.auth.uid == userId;
}

What is the main issue if you want users to read their posts stored in a subcollection posts under their user document?

medium

A. The rule does not cover the posts subcollection, so access is denied

B. The rule allows anyone to read posts

C. The rule allows write but not read

D. The rule only works for admin users

Solution

1. Step 1: Analyze the rule scope

   The rule matches only the /users/{userId} document, not any subcollections like posts.

2. Step 2: Effect on subcollections

   Without explicit rules for /users/{userId}/posts/{postId}, access to posts is denied by default.

3. Final Answer:

   The rule does not cover the posts subcollection, so access is denied -> Option A

4. Quick Check:

   Security rules must cover subcollections explicitly [OK]

Hint: Rules must match subcollections separately to allow access [OK]

Common Mistakes:

• Assuming parent document rules apply to subcollections
• Believing rules allow all reads by default
• Confusing read and write permissions

5. You want to design a Firestore data model for a chat app where users can have many messages. Which approach follows best practices for scalability and easy querying?

hard

A. Store all messages in a single collection with a userId field to filter messages

B. Store messages as an array field inside each user document

C. Create a messages subcollection under each user document

D. Store messages in a single document with nested objects for each message

Solution

1. Step 1: Consider scalability needs

   Storing many messages inside one document or array can cause size limits and slow queries.

2. Step 2: Use subcollections for many related items

   Creating a messages subcollection under each user document allows efficient queries and scales well.

3. Final Answer:

   Create a messages subcollection under each user document -> Option C

4. Quick Check:

   Use subcollections for large, related data sets [OK]

Hint: Use subcollections for many related items to avoid document size limits [OK]

Common Mistakes:

• Putting many items in arrays inside documents
• Using one big collection without filtering
• Storing all data in one document causing size errors