Firestore - direct or indirect query

[benomatis]

Not necessarily intentionally but my web app is currently set up to get or list data from firestore querying directly while creating and updating works via function using the admin SDK. However, I'm not sure it's the best approach from the perspective of performance, cost and security.

One of the main reasons Iike indirect access (functions with admin SDK) is because the code is hidden, however I just read here (https://medium.com/firebase-developers/should-i-query-my-firebase-database-directly-or-use-cloud-functions-fbb3cd14118c) that it's potentially slower and could even cost more as there is no local caching, though not sure how much local caching would go into updating records.

The app in question is a PWA (using gatsby framework for react), with rematch (a react redux framework), a booking app, let's make it an event booking system, to make it easier to refer to. The most recent bit I finished was user management, defining how users can create other users, update themself or others, or remove their association with them.

As above described, users would get their associated user list via direct querying methods, while creating new users or updating them goes indirectly (callable functions using the admin SDK).

I'm contemplating moving everything back to my client app to query / update firestore directly, which would help by being able to leverage the rules more, however, it would expose more of the code, potentially there for hackers to exploit.

What would be one or more factprs that would help me decide where to actually do the processing of read or write (I don't delete, just disable)?

Thank you in advance.

Cheers,

benomatis

[Kato Richardson]

Hello Benomatis,

As a general rule, don't introduce a proxy between the API and your clients without a solid reason. Controlling security and what can be written can be done using security rules. You will likely reduce security by using Functions as an intermediary and you will certainly increase latency and cost at scale.

A good reason to introduce Functions into the mix is when you need to do complex validations (e.g. in-game trading logic, IP based throttling, et al), but not for basic security and certainly not for cost or performance.

☼, Kato

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/fcdb596e-41da-46cc-b708-78a4b30461a8n%40googlegroups.com.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

[benomatis]

Thanks so much, Kato, it makes perfect sense!

[benomatis]

Sorry, Kato, I just realized one important detail: if I want to create or update users other than the currently logged in user, I have no choice but to use the admin sdk in a separate api or callable functions, is that correct?

[Kato Richardson]

What do you mean by create or update users? Is this updating a profile in the database? What's the actual use case you're trying to resolve? User registration perhaps?

☼, Kato

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/514bcd9f-e6b9-43eb-b65c-1786a91bf416n%40googlegroups.com.

[Benjamin Matis]

Yes, user registration and management, ie. I'm providing a platform for admins to be able to create and update users.

You received this message because you are subscribed to a topic in the Google Groups "Firebase Google Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firebase-talk/Md4SuZbfQ6M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firebase-tal...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CADypTEZwMh76z66EosL%3D2EBudbWF3Moy%3DKQGLhMMrkMcstv6qA%40mail.gmail.com.

[Kato Richardson]

Registration should be managed by storing profiles in a database or assigning custom claims. You cannot prevent users from creating Auth credentials, but that also doesn't inherently give them any access, just a user id. It's up to you to gate access based on some property of the user account.

☼, Kato

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CAFggDEW5gXfVk0KPKfgckXTmG5tY7Zdj7xCZbMzUe7rr21uG9w%40mail.gmail.com.

[Benjamin Matis]

sorry, I meant user creation, classic registration is self-service, as it should be, but admins can create other users. My point it: I cannot really move user creation and update functions to the client app as it would then require me to log in to the newly created account or the one to be updated every time an admin creates a new account.

But this is fine: I'll keep user management in callable functions, while the rest will be used from the client app.

Thank you for your help.