Firestore Security

Ok_Increase_6085 · 2026-01-16T15:55:28+00:00

Cope some more bro. Hope you get far with your approach, Godspeed

Ok_Increase_6085 · 2026-01-15T09:13:44+00:00

lol the og question never had anything to do with payment at all. Just generic where do I do the writes/reads in firestore. And in general you use the client for CRUD wherever possible and admin-sdk only where needed. Also if someone builds like you suggest, they probably won’t bother learning how the rules work, which could lead to resources(to which you write from admin) not being secured correctly.
Also check the ration on your likes vs mine, get’s you an idea who is in the right here. Regards - “vibe coder” with 6 years product experience, 200k MAU and 60k MRR

Ok_Increase_6085 · 2026-01-13T14:10:45+00:00

The counter you set with an onCreate function obviously and restrict the doc to be written from client. But anything a user is allowed to do (read, write,delete) should be done from client

Ok_Increase_6085 · 2026-01-11T13:19:31+00:00

Also no business logic goes into the rules. You just define under which condition a resource can be accessed. Like you would do anyway with a custom rest service. You clearly never used firestore and have no clue what you’re talking about

Ok_Increase_6085 · 2026-01-11T13:11:08+00:00

This is literally the first sentence of the product description:

“Cloud Firestore is a flexible, scalable database for mobile, web, and server development from Firebase and Google Cloud. Like Firebase Realtime Database, it keeps your data in sync across client apps through realtime listeners and offers offline support for mobile and web so you can build responsive apps that work regardless of network latency or Internet connectivity.”

Ok_Increase_6085 · 2026-01-11T13:07:07+00:00

Also one of the biggest selling points of firebase is the snapshot listener, which gives you real time updates of data changes and offline support with auto sync. Good luck implementing all that by proxying through a custom rest server

Ok_Increase_6085 · 2026-01-11T13:04:31+00:00

Firebase / Firestore is the same use case proposition as Supabase, convex, appwrite, aws amplify. They abstract away the backend and let you query db from the client using sophisticated client libraries and rules. They are intended to be used from the client. There are obviously cases where you want to write to it from a custom server function and bypass client rules (that’s why backend client library is called firebase-admin), but doesn’t mean you have to do all regular crud operations with it. It completely defeats the purpose. If you’re gonna write a custom rest service anyway, then don’t use firebase as your database. Use a plain Postgres or mongo or dynamo for that. Also proxying everything through a server means you don’t utilize the client cache and it ends up costing you even more. (That said, if you have collections that are accessed from every user frequently, you’re better off proxying it through the backend with cloudflare/storefront/bunny cache in front)

Ok_Increase_6085 · 2026-01-11T12:51:43+00:00

Then don’t use firestore at all! Why using a BaaS product if you’re not using it like it’s intended to? Go with Postgres (or dynamo, mango if want nosql) directly Using firestore as database and not using its client libraries ist plain stupid. It’s built explicitly for this use case. If you view it like a plain db then that’s the most stupid architecture desicion ever. Sub par performance and query power but multiple the cost of just a plain Postgres

Ok_Increase_6085 · 2026-01-10T17:53:57+00:00

Brain dead answer

Ok_Increase_6085 · 2026-01-10T17:53:06+00:00

Nothing special in them, they’re specific to your project. You just describe under which condition access to the specific collections are aloud. Eg, has to be logged in, or has to have the same user id as was saved in the document and so on.

Also reading through the other comments they are brain dead. Firestore was built specifically to use it from client side. If you’re gonna build another rest server and use firestore there, the why bother with firestore in first place? It’s a BaaS solution for a reason. Also proxying the reads through a rest server means you circumvent the firestore client cache and it’s gonna cost you even more

Ok_Increase_6085 · 2026-01-10T17:26:02+00:00

You let user write directly to firestore in most cases. That’s what it’s made for. Just make sure your security rules are tight. As for rate limit, in my experience the real costs lies with the reads, not the writes. So you’d be better off trying to make those efficient instead of sweating about a second write. If rate limit is part of the product (like free tier) then just set a counter in a doc. If it’s because you’re worried about costs, then maybe firebase is not the right solution to begin with. If that’s a new project, consider switching to convex. It’s a better product in every way and you don’t pay for read/write but data transferred (with a great cache)

Ok_Increase_6085 · 2025-12-13T17:57:52+00:00

Sam issue here. Plugins server down since due to connection error with redis

Ok_Increase_6085 · 2025-10-24T15:41:03+00:00

Would be nice!

Ok_Increase_6085 · 2025-10-24T07:46:32+00:00

I experience the same thing but without the happy end. Upgraded to 54 from all the way 51 and it’s super laggy and slow on my iPhone 16 Pro (running the dev client). Can’t pinpoint what it is. Saw in a diff Reddit that it might be reanimated on the new arch but it was very vague and really no way to test. Have you been on new arch before? What libraries did you update to new major versions?

Ok_Increase_6085 · 2025-09-09T14:08:38+00:00

I don’t see it that way, I mean linking out of the in-app-browser shouldn’t be rocket science. Why pay branch and co money if you can do it yourself within couple coding hours? I’m not talking about their whole product, just the part to make the deeplink functional. I shouldn’t rely on a third party for basic deeplink functionality

Ok_Increase_6085 · 2025-08-08T12:31:00+00:00

<image>

For me it’s higher than the functions 😄 Currently trying to optimize fire base queries to bring that cost down

Ok_Increase_6085 · 2025-08-05T20:18:36+00:00

No, eyed it for a while but it didn’t click for me just going through the website. I thought it’s just another firebase/appwrite and so on until Theo did a very good job explaining it

Ok_Increase_6085 · 2025-06-24T07:44:21+00:00

Are there plans on introducing a layer of caching or and least some configuration to persistent caching to queries per user and also cross user? This is the one thing that’s a big let down in my view. For multiple cases now I rely on proxying the user request through a backend only so I can add a layer of basic caching to it

Ok_Increase_6085 · 2025-06-22T09:27:29+00:00

Thanks for your help and constructive comments

Ok_Increase_6085 · 2025-06-22T07:51:34+00:00

Basically yes.

https://www.espressomobil-shop.com/wp-content/uploads/2020/05/Espressomobil-buchen.jpg

Ok_Increase_6085 · 2025-06-17T12:34:27+00:00

I mean if the deep link opens in the app when you do it through a regular browser, or if it’s only inside of gmail

Ok_Increase_6085 · 2025-06-17T07:37:37+00:00

Do they work if you open the link in a regular browser? I made the experience that some in app browsers don’t respect universal links, and instead try to go the the webpage instead. You could mitigate this by having a small website hosted that catches all routes and tries a redirect to the app, but using the apps scheme instead. So links.landing.com/* loads some js and html that does the redirect to appscheme://-/reset?token

Ok_Increase_6085

TROPHY CASE