Real-time updates with listeners in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

How does a Firestore listener behave on document update?

You set up a Firestore listener on a document to get real-time updates. What happens when the document is updated?

A The listener triggers only if the document is deleted, not on updates.

B The listener triggers only once when first attached and never again.

C The listener triggers only if the document is created, not on updates.

D The listener triggers once immediately and then again every time the document changes.

💡 Hint

Think about how real-time updates work in Firestore listeners.

Firestore listeners trigger immediately with the current document data and then again every time the document changes, providing real-time updates.

❓ Architecture

intermediate

Best architecture for real-time updates with Cloud Pub/Sub

You want to build a system that sends real-time updates from a backend to multiple clients. Which architecture best supports this using Cloud Pub/Sub?

A Backend publishes messages to a Pub/Sub topic; clients subscribe directly to the topic to receive updates.

B Clients publish messages to a Pub/Sub topic; backend subscribes to process updates.

C Backend writes updates to Cloud Storage; clients poll the storage for changes.

D Backend sends HTTP requests directly to clients without Pub/Sub.

💡 Hint

Consider how Pub/Sub supports message distribution to multiple subscribers.

Cloud Pub/Sub allows the backend to publish messages to a topic, and multiple clients can subscribe to that topic to receive real-time updates efficiently.

❓ security

advanced

Securing Firestore listeners for real-time updates

You want to ensure only authorized users receive real-time updates from Firestore listeners. Which method best enforces this?

A Encrypt data on the client side before sending it to Firestore.

B Use Firestore security rules to restrict read access based on user authentication and document fields.

C Disable Firestore listeners and use polling instead.

D Use a VPN to restrict network access to Firestore.

💡 Hint

Think about how Firestore controls access to data.

Firestore security rules allow fine-grained control over who can read documents, ensuring listeners only receive updates they are authorized to see.

❓ Configuration

advanced

Configuring Cloud Functions to trigger on Firestore updates

Which Cloud Function trigger configuration correctly listens to document updates in Firestore?

A functions.firestore.document('collection/{docId}').onDelete((snap, context) => { ... })

B functions.firestore.document('collection/{docId}').onCreate((snap, context) => { ... })

C functions.firestore.document('collection/{docId}').onUpdate((change, context) => { ... })

D functions.pubsub.topic('topicName').onPublish((message) => { ... })

💡 Hint

Focus on the trigger that responds to document updates.

The onUpdate trigger listens specifically for changes to existing Firestore documents.

✅ Best Practice

expert

Optimizing Firestore listeners for cost and performance

You have many clients listening to Firestore documents for real-time updates. What is the best practice to reduce costs and improve performance?

A Use collection group queries with listeners to reduce the number of listeners needed.

B Use polling every few seconds instead of listeners to reduce Firestore reads.

C Set up a listener on each individual document separately for precise updates.

D Disable offline persistence on clients to reduce local storage usage.

💡 Hint

Think about how to minimize the number of active listeners.

Collection group queries allow a single listener to monitor multiple documents across collections, reducing the number of listeners and Firestore reads, which saves cost and improves performance.

Practice

1. What is the main purpose of using a listener like onSnapshot in Google Firestore?

easy

A. To get real-time updates automatically when data changes

B. To manually refresh the data in the app

C. To delete documents from the database

D. To backup data to another storage

Solution

1. Step 1: Understand what onSnapshot does

   onSnapshot listens to changes in Firestore data and updates the app instantly.

2. Step 2: Compare options with onSnapshot purpose

   Only To get real-time updates automatically when data changes describes getting real-time updates automatically, which matches onSnapshot.

3. Final Answer:

   To get real-time updates automatically when data changes -> Option A

4. Quick Check:

   Real-time updates = To get real-time updates automatically when data changes [OK]

Hint: Remember: listeners auto-update data without refresh [OK]

Common Mistakes:

• Thinking listeners require manual refresh
• Confusing listeners with data deletion
• Assuming listeners backup data

2. Which of the following is the correct syntax to start listening to a Firestore collection named users using onSnapshot?

easy

A. db.onSnapshot('users', snapshot => { /* handle data */ });

B. db.listen('users').onSnapshot(snapshot => { /* handle data */ });

C. db.collection('users').listen(snapshot => { /* handle data */ });

D. db.collection('users').onSnapshot(snapshot => { /* handle data */ });

Solution

1. Step 1: Recall Firestore listener syntax

   The correct method to listen to a collection is db.collection('name').onSnapshot(callback).

2. Step 2: Match options with correct syntax

   Only db.collection('users').onSnapshot(snapshot => { /* handle data */ }); matches the correct Firestore syntax for listening to a collection.

3. Final Answer:

   db.collection('users').onSnapshot(snapshot => { /* handle data */ }); -> Option D

4. Quick Check:

   Correct Firestore listener syntax = db.collection('users').onSnapshot(snapshot => { /* handle data */ }); [OK]

Hint: Use db.collection('name').onSnapshot(callback) for listeners [OK]

Common Mistakes:

• Using .listen instead of .onSnapshot
• Calling onSnapshot directly on db
• Passing collection name as first argument to onSnapshot

3. Consider this code snippet listening to a Firestore document:

const unsubscribe = db.collection('tasks').doc('task1').onSnapshot(doc => {
  console.log(doc.data().status);
});

If the document's status field changes from 'pending' to 'done', what will be printed?

medium

A. 'pending' then 'done' printed once each

B. Only 'pending' printed once

C. Only 'done' printed once

D. No output printed

Solution

1. Step 1: Understand onSnapshot behavior on document changes

   onSnapshot triggers immediately with current data, then again on any change.

2. Step 2: Trace output for status change

   Initially, 'pending' is printed. When status changes to 'done', listener triggers again and prints 'done'.

3. Final Answer:

   'pending' then 'done' printed once each -> Option A

4. Quick Check:

   Listener prints on initial and update = 'pending' then 'done' printed once each [OK]

Hint: Listeners print initial and updated data automatically [OK]

Common Mistakes:

• Thinking listener triggers only on updates, not initially
• Expecting no output if data changes
• Confusing document and collection listeners

4. You wrote this code to listen to a Firestore collection but notice your app slows down over time:

db.collection('messages').onSnapshot(snapshot => {
  // update UI
});

What is the most likely cause and how to fix it?

medium

A. You used the wrong collection name; fix by correcting the name.

B. You need to refresh the page to update data; fix by adding a refresh button.

C. You forgot to unsubscribe; fix by saving and calling the unsubscribe function when done.

D. You should use setTimeout to delay the listener; fix by adding delay.

Solution

1. Step 1: Identify cause of app slowdown with listeners

   Not unsubscribing causes multiple active listeners, slowing app.

2. Step 2: Apply best practice to unsubscribe

   Save the unsubscribe function returned by onSnapshot and call it when listener is no longer needed.

3. Final Answer:

   You forgot to unsubscribe; fix by saving and calling the unsubscribe function when done. -> Option C

4. Quick Check:

   Unsubscribe to avoid slowdowns = You forgot to unsubscribe; fix by saving and calling the unsubscribe function when done. [OK]

Hint: Always unsubscribe listeners to keep app fast [OK]

Common Mistakes:

• Ignoring unsubscribe causing memory leaks
• Trying to refresh page instead of fixing listener
• Adding delays instead of proper cleanup

5. You want to build a chat app that shows new messages instantly using Firestore listeners. Which approach best ensures efficient real-time updates and resource management?

hard

A. Load all messages once on app start and never update again.

B. Use onSnapshot on the messages collection, update UI on changes, and unsubscribe when user leaves chat.

C. Use periodic polling every 5 seconds to fetch messages and update UI.

D. Use onSnapshot but never unsubscribe to keep updates always.

Solution

1. Step 1: Choose real-time update method

   onSnapshot provides instant updates, better than polling or one-time load.

2. Step 2: Manage resources properly

   Unsubscribing when user leaves prevents unnecessary listeners and saves resources.

3. Final Answer:

   Use onSnapshot on the messages collection, update UI on changes, and unsubscribe when user leaves chat. -> Option B

4. Quick Check:

   Real-time + unsubscribe = Use onSnapshot on the messages collection, update UI on changes, and unsubscribe when user leaves chat. [OK]

Hint: Real-time updates + unsubscribe = efficient app [OK]

Common Mistakes:

• Using polling instead of listeners
• Never unsubscribing causing leaks
• Loading data only once without updates