Considering the recent decision by Google to implement charges for nearly every aspect of Firebase Firestore and Firebase Cloud function usage, it is essential to optimize our code to ensure efficient execution of queries to Firestore.
I am currently conducting isolated tests to validate Firebase's usage statistics accuracy. Upon initial examination, there seems to be some discrepancy.
An interesting observation is the instantiation of an observable within the constructor of my authentication service in an Angular application during app launch, resulting in over 70 read requests. How can this be justified?
No modifications were made to the data before or after creating this observable instance.
After allowing the usage to stabilize, we launched one instance of our application following an hour of zero activity. The aforementioned observable was initiated:
this.auth$ = this.firebaseAuth.authState.pipe(
switchMap((user) => {
if (user) {
console.log("[auth service] user update:", user);
return this.firestore.doc(`users/${user.uid}`).valueChanges();
} else {
console.log("[auth service] user not signed in");
return of(null);
}
})
);The application was closed immediately after loading.
About five minutes later, we checked the usage stats on the Firebase console only to find 70+ additional read requests against our quota. Why did this happen?
Update 1
Responding to comments below and as previously suspected, keeping the Firebase console open in a browser might contribute to extra hits on our quota. However, this explanation does not fully account for the 70+ read requests from our initial test. Could the console potentially generate reads even without navigating around? For instance, could it load unselected data such as an entire collection?