Reading data (once and listener) in Firebase - Time & Space Complexity

Time Complexity: Reading data (once and listener)

O(1) for once, O(m) for listener

Understanding Time Complexity

When we read data from Firebase, the time it takes depends on how much data we ask for and how often we listen for changes.

We want to understand how the number of reads grows as the data size or listening time grows.

Scenario Under Consideration

Analyze the time complexity of reading data once and using a listener.

// Read data once
firebase.database().ref('items').once('value').then(snapshot => {
  console.log(snapshot.val());
});

// Listen for data changes
firebase.database().ref('items').on('value', snapshot => {
  console.log(snapshot.val());
});
    

This code reads all data under 'items' once, then sets a listener to get updates whenever data changes.

Identify Repeating Operations

Look at the main Firebase calls and how often they happen.

• Primary operation: Reading data from the database (once or on each change)
• How many times: Once for the single read; multiple times for the listener, once per data change

How Execution Grows With Input

Reading once means one operation regardless of data size, but the data size affects how much data is transferred.

Input Size (n items)	Approx. API Calls/Operations
10	1 read call
100	1 read call
1000	1 read call

For the listener, each data change triggers one read operation, so the number of reads grows with the number of changes.

Number of Changes (m)	Approx. API Calls/Operations
10	10 read calls
100	100 read calls
1000	1000 read calls

Pattern observation: Single read is constant; listener reads grow linearly with changes.

Final Time Complexity

Time Complexity: O(1) for reading once, O(m) for listener with m changes

This means reading once takes the same time no matter data size, but listening grows with how many updates happen.

Common Mistake

[X] Wrong: "Listening to data changes only costs one read operation total."

[OK] Correct: Each time data changes, Firebase sends a new read operation, so costs add up with changes.

Interview Connect

Understanding how data reads scale helps you design apps that stay fast and cost-effective as they grow.

Self-Check

What if we only listen to a small part of the data instead of the whole 'items' node? How would the time complexity change?

Practice

1. Which Firebase function should you use to read data only once from the database?

easy

A. onValue()

B. set()

C. get()

D. push()

Solution

1. Step 1: Understand the purpose of get()

   The get() function reads data from Firebase once and returns a promise with the data snapshot.

2. Step 2: Compare with onValue()

   onValue() listens continuously for data changes, not just once.

3. Final Answer:

   get() -> Option C

4. Quick Check:

   Read data once = get() [OK]

Hint: Use get() for one-time reads, not listeners [OK]

Common Mistakes:

• Confusing get() with onValue()
• Using set() which writes data
• Using push() which adds new data

2. Which of the following is the correct syntax to listen for real-time updates on a Firebase database reference ref?

easy

A. onValue(ref, snapshot => { ... })

B. ref.onValue(snapshot => { ... })

C. ref.listen(snapshot => { ... })

D. ref.get().then(snapshot => { ... })

Solution

1. Step 1: Recall the correct onValue usage

   The Firebase real-time listener uses the function onValue(ref, callback) to listen for changes.

2. Step 2: Check other options for syntax errors

   ref.onValue is incorrect because onValue is a standalone function, not a method on ref. ref.get() reads once, and ref.listen does not exist.

3. Final Answer:

   onValue(ref, snapshot => { ... }) -> Option A

4. Quick Check:

   Listener syntax = onValue(ref, callback) [OK]

Hint: Remember: onValue takes ref as first argument [OK]

Common Mistakes:

• Calling onValue as a method on ref
• Using get() for continuous listening
• Using non-existent listen() method

3. What will be logged to the console when the following code runs and the database value at ref is { name: 'Alice' }?

onValue(ref, snapshot => {
  console.log(snapshot.val());
});

medium

A. null

B. undefined

C. Error

D. { name: 'Alice' }

Solution

1. Step 1: Understand onValue callback behavior

   The callback receives a snapshot of the current data at ref. Calling snapshot.val() returns the data object.

2. Step 2: Check the database value

   The database value at ref is { name: 'Alice' }, so snapshot.val() returns this object.

3. Final Answer:

   { name: 'Alice' } -> Option D

4. Quick Check:

   snapshot.val() returns current data [OK]

Hint: Remember: snapshot.val() gives current data [OK]

Common Mistakes:

• Expecting snapshot itself to be data
• Confusing null with empty data
• Assuming an error if data exists

4. Consider this code snippet:

const unsubscribe = onValue(ref, snapshot => {
  console.log(snapshot.val());
});

// Later in the code
unsubscribe();

What is the purpose of calling unsubscribe() here?

medium

A. To fetch data one more time

B. To stop listening for real-time updates

C. To reset the database reference

D. To delete the data at ref

Solution

1. Step 1: Understand the return value of onValue

   onValue returns a function that, when called, stops the listener from receiving further updates.

2. Step 2: Analyze the effect of calling unsubscribe()

   Calling unsubscribe() removes the listener, so no more console logs happen on data changes.

3. Final Answer:

   To stop listening for real-time updates -> Option B

4. Quick Check:

   Calling unsubscribe stops listener [OK]

Hint: Call unsubscribe to stop real-time listeners [OK]

Common Mistakes:

• Thinking unsubscribe fetches data
• Confusing unsubscribe with data deletion
• Assuming unsubscribe resets reference

5. You want to read user profile data once and then listen for any updates to the user's status in real-time. Which code snippet correctly implements this using Firebase?

hard

A. get(userRef).then(snapshot => {
console.log(snapshot.val());
});
onValue(statusRef, snapshot => {
console.log('Status:', snapshot.val());
});

B. onValue(userRef, snapshot => {
console.log(snapshot.val());
});
get(statusRef).then(snapshot => {
console.log('Status:', snapshot.val());
});

C. get(userRef).then(snapshot => {
console.log(snapshot.val());
});
get(statusRef).then(snapshot => {
console.log('Status:', snapshot.val());
});

D. onValue(userRef, snapshot => {
console.log(snapshot.val());
});
onValue(statusRef, snapshot => {
console.log('Status:', snapshot.val());
});

Solution

1. Step 1: Read user profile data once

   Use get(userRef) to read the profile data once and log it.

2. Step 2: Listen for real-time updates on user status

   Use onValue(statusRef, callback) to listen continuously for status changes.

3. Step 3: Verify other options

   onValue(userRef, snapshot => {
     console.log(snapshot.val());
   });
   get(statusRef).then(snapshot => {
     console.log('Status:', snapshot.val());
   });

   reverses the roles, reading status once and listening to profile continuously, which is incorrect.

   get(userRef).then(snapshot => {
     console.log(snapshot.val());
   });
   get(statusRef).then(snapshot => {
     console.log('Status:', snapshot.val());
   });

   reads both once, no listener.

   onValue(userRef, snapshot => {
     console.log(snapshot.val());
   });
   onValue(statusRef, snapshot => {
     console.log('Status:', snapshot.val());
   });

   listens to both continuously, no one-time read.

4. Final Answer:

   Use get() for profile once and onValue() for status listener -> Option A

5. Quick Check:

   One-time read + listener = get() + onValue() [OK]

Hint: Combine get() for once and onValue() for listening [OK]

Common Mistakes:

• Using onValue for both reads
• Using get() for listening
• Mixing up which data needs listening