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.

CodePudding user response：

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.