Nested objects and arrays in Firebase - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

How does Firebase Realtime Database handle nested arrays?

Consider storing a list of user scores inside a Firebase Realtime Database node as a nested array. What happens when you update a single element inside this array?

A Firebase throws an error because nested arrays are not supported.

B Only the updated element is changed without affecting other elements.

C The entire array is overwritten with the new array including the updated element.

D The updated element is appended to the array instead of replacing the existing one.

💡 Hint

Think about how Firebase treats arrays internally as objects with numeric keys.

Firebase Realtime Database treats arrays as objects with numeric keys. When you update one element, you must write the entire array; partial updates to array elements are not supported. So the whole array is overwritten.

❓ Architecture

intermediate

Best practice for storing nested objects in Firestore

You want to store a user's profile with multiple addresses inside Firestore. Which approach is best for efficient querying and scalability?

A Store addresses in a separate collection unrelated to the user document.

B Store addresses as a single string field with comma-separated values.

C Store all addresses as a nested array inside the user document.

D Store each address as a separate document in a subcollection under the user document.

💡 Hint

Consider how Firestore handles large nested arrays and querying individual addresses.

Storing addresses as separate documents in a subcollection allows efficient querying, updating, and scaling. Nested arrays inside documents can become large and inefficient to query or update.

❓ security

advanced

Securing nested objects in Firestore with rules

You have a Firestore document with a nested object containing sensitive user settings. Which security rule correctly restricts read access only to the owner of the document?

Firebase

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

A allow read: if request.auth.uid == userId;

B allow read: if request.auth.uid == userId && resource.data.settings != null;

C allow read: if request.auth.token.admin == true;

D allow read: if resource.data.settings.owner == request.auth.uid;

💡 Hint

Think about how to restrict access to the whole document based on user ID.

Rule B correctly restricts read access to the document only if the authenticated user ID matches the document ID. Nested object fields do not need separate rules if the whole document is protected.

❓ Configuration

advanced

Handling deeply nested objects in Firebase Realtime Database

You have a deeply nested object structure in Firebase Realtime Database. Which approach minimizes data transfer and improves update performance?

A Store the entire nested object as a single node and update it fully on changes.

B Flatten the nested structure by using dot notation keys and update only changed parts.

C Convert nested objects to JSON strings and store as text fields.

D Use multiple separate nodes for each nested level and update them independently.

💡 Hint

Consider how Firebase allows partial updates using paths.

Using dot notation keys to flatten nested objects lets you update only the changed parts without rewriting the entire object, reducing data transfer and improving performance.

✅ Best Practice

expert

Optimizing Firestore data model for nested arrays with frequent updates

You have a Firestore document with a nested array of comments that are frequently updated individually. What is the best data modeling approach to optimize performance and avoid contention?

A Store each comment as a separate document in a subcollection under the main document.

B Store comments as a JSON string inside a single field and update the string on changes.

C Store comments as a map with comment IDs as keys inside the document.

D Keep comments as a nested array inside the document and update the entire array on each comment change.

💡 Hint

Think about Firestore's document size limits and update contention.

Storing each comment as a separate document in a subcollection avoids large document size and reduces contention because updates happen on individual documents, not the whole array.