Ordering results in Firebase - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Ordering Firestore query results by a single field

You have a Firestore collection named products with documents containing a price field. You want to retrieve all products ordered by price from lowest to highest.
Which query will return the products correctly ordered by price ascending?

A db.collection('products').orderBy('price', 'asc').get()

B db.collection('products').orderBy('price', 'desc').get()

C db.collection('products').orderBy('price').get()

D db.collection('products').orderBy('price', 'ascending').get()

💡 Hint

Remember that Firestore orderBy accepts 'asc' or 'desc' as direction strings.

Option A uses the correct method to order by 'price' ascending using 'asc'. Option A orders descending, so order is reversed. Option A omits the direction, which defaults to ascending but is less explicit. Option A uses 'ascending' which is invalid and causes an error.

❓ Configuration

intermediate

Ordering Realtime Database results by child key

You want to retrieve all users from Firebase Realtime Database ordered by their age field.
Which query correctly orders the users by age ascending?

A firebase.database().ref('users').orderByValue('age').once('value')

B firebase.database().ref('users').orderByChild('age').once('child_added')

C firebase.database().ref('users').orderByKey('age').once('value')

D firebase.database().ref('users').orderByChild('age').once('value')

💡 Hint

Use orderByChild to order by a specific child key.

Option D correctly orders by the child key 'age' and retrieves the full snapshot once. Option D tries to order by key but passes 'age' which is invalid. Option D orders by value but 'age' is a child, not the value itself. Option D uses 'child_added' event which triggers multiple times, not a single snapshot.

❓ Architecture

advanced

Designing Firestore queries with multiple orderBy clauses

You have a Firestore collection tasks with fields priority (number) and dueDate (timestamp). You want to query tasks ordered first by priority ascending, then by dueDate descending.
Which query correctly implements this ordering?

A db.collection('tasks').orderBy('priority', 'asc').orderBy('dueDate', 'desc').get()

B db.collection('tasks').orderBy('dueDate', 'desc').orderBy('priority', 'asc').get()

C db.collection('tasks').orderBy('priority').orderBy('dueDate').get()

D db.collection('tasks').orderBy('priority', 'desc').orderBy('dueDate', 'asc').get()

💡 Hint

The order of orderBy calls matters and direction must be specified explicitly when descending.

Option A orders by priority ascending first, then dueDate descending as required. Option A reverses the order of fields. Option A orders both ascending by default, not matching the requirement. Option A reverses directions.

❓ security

advanced

Firestore security rules impact on ordered queries

You have a Firestore collection messages with a field timestamp. You want to allow users to read messages ordered by timestamp.
Which security rule snippet correctly allows read access only if the query orders by timestamp ascending?

A allow read: if request.query.orderByField == 'timestamp' && request.query.orderByDirection == 'asc';

B allow read: if request.query.orderBy[0].field == 'timestamp' && request.query.orderByDirection[0] == 'ASC';

C allow read: if request.query.orderBy == 'timestamp' && request.query.orderByDirection == 'asc';

D allow read: if request.query.orderBy == ['timestamp'] && request.query.orderByDirection == ['asc'];

💡 Hint

Firestore security rules use arrays for orderBy and orderByDirection properties.

Option B correctly checks the first element of orderBy and orderByDirection arrays. Option B compares arrays directly which is invalid. Options B and C use incorrect property names or types.

✅ Best Practice

expert

Optimizing Firestore queries with ordering and indexing

You have a Firestore collection orders with fields status (string) and createdAt (timestamp). You want to query orders where status is 'pending' ordered by createdAt descending.
Which approach is best to ensure the query is efficient and does not require manual index creation?

A Query with orderBy('createdAt', 'desc') only and filter status client-side

B Query with where('status', '==', 'pending').orderBy('status').orderBy('createdAt', 'desc') without creating indexes

C Create a composite index on status ascending and createdAt descending, then query with where('status', '==', 'pending').orderBy('createdAt', 'desc')

D Query with where('status', '==', 'pending').orderBy('createdAt', 'desc') and rely on Firestore to auto-create the index

💡 Hint

Firestore requires composite indexes for queries with multiple filters and orderBy on different fields.

Option C creates the required composite index explicitly, ensuring efficient queries. Option C orders by status unnecessarily and lacks index. Option C relies on auto-index creation which may cause runtime errors until index is created. Option C filters client-side which is inefficient and costly.