0

Is it bad to use the client-side Firestore SDK on the server side? I am building a service that is constantly polling an API and updating a database.

I like how it uses the modular approach and how there is an immense supply of documentation it supplies compared to the Admin-SDK approach. My thoughts were creating an immensely long password, adding the user in the Firebase Auth console and storing the login information locally so it is never tracked by git. In theory, isn't it the same approach that the Admin-SDK uses when it tells you to generate the private key file and save that on your machine locally?

Feels like using the client-side Firestore-SDK (firebase/firestore) rather then using the Admin-SDK(firebase-admin/firestore) there is more support (documentation) and the code is much cleaner looking.

Let me know if I am missing something here because at this point I really don't see the benefit of the admin-sdk. Other than closing security rules to all. But if you only have one user in theory you can adjust security rules so only that one authenticated user is allowed to read and write. Which in my case would be the 'user'/credentials the server uses. I feel like admin-sdk is more of a pain than it is a benefit.

But I'm opened to have my mind changed and to receive guidance on this issue.

Mario Lopez
  • 67
  • 1
  • 10

1 Answers1

1

Is it bad to use the client-side Firestore SDK on the server side?

Nope, not at all. If this SDK meets your requirements, then go for it.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • Thanks for responding Frank. Is authenticating the way I mentioned above the best way of using the client-side firestore? As in storing a local password and limiting the security rule to that user? Or is there a better way to use the client-side firestore sdk on a server? – Mario Lopez Nov 21 '21 at 18:26
  • "the best way" is just somebody's opinion. I prefer using the Admin SDK for my administrative code in trusted environments, and in cases where the code/documentation of that isn't clear to me, I try to find an answer to *that* problem instead of working around it by using the client-side SDK. If I need a client-side application administrator, I *do* sometimes start by hard-coding their UID in my security rules. But that's when I use client-side code, so for an application administrator. For server-side/trusted code, I use the Admin SDK. – Frank van Puffelen Nov 21 '21 at 20:57
  • For more on allowing an application administrator in your security rules, also see: https://stackoverflow.com/questions/65553664/firestore-security-rules-allow-access-to-one-specific-user/65553986#65553986, and https://stackoverflow.com/questions/56442795/declaring-a-function-in-firestore-rules/56444700#56444700 You can also set a custom Admin claim and check that, as shown here: https://stackoverflow.com/questions/60179115/firebase-security-rule-to-allow-admin-users-to-read-write-all-other-users-create/60179711#60179711. – Frank van Puffelen Nov 21 '21 at 20:58
  • Awesome thank you for this! Out of curiosity, since you work on the firebase team, do you know why `firebase-admin/firestore` is different from `firebase/firestore` I feel like `firebase/firestore` can be used just as well or why have to separate libraries if they can essentially do the same things? – Mario Lopez Nov 22 '21 at 05:09
  • The two SDKs share a lot of code under the hood, but have different purposes. One is for use in administrative tasks in privileged environments, the other is for use in unprivileged, client-side code. – Frank van Puffelen Nov 22 '21 at 15:03