- Lack of schema makes it really easy write bad data without realising it. I inherited a 3 year old firebase/firestore codebase and database was FULL of inconsistent data. This was not helped by our application being in JavaScript meaning bad data could roundtrip all the way through our without triggering any errors. Only later causing obscure and hard to debug issues.
- Lack of query flexibility or joins make some use cases either impossible or very inefficient
- Connecting directly from client apps makes it very difficult to make backwards compatible changes. You can fix this by making everything go through backend APIs, but then you lose realtime which is the main benefit of firestore in the first place.
We're halfway through a port to Postgres+Hasura, and our app is much more reliable and responsive now.
I have seen people putting bad security rules often before. It makes me worried about using firebase apps.
No proper rate limiting, protected fields, dashboard sucks, opened feature requests for years without any answers, missing ton of small stuff I can't remember that is very easy to do on postgres (counters?), etc.
I have used hasura. It's good but I like supabase more now. Easier to directly write SQL than indirection of graphql.
Those security rules tools look excellent. I had no idea that security rules could restrict the data shape. Our app only has basic read permissions configured (and we're not bothering updating them because we're moving all the data our of firebase anyway).
> I have used hasura. It's good but I like supabase more now. Easier to directly write SQL than indirection of graphql.
Supabase looks really nice. I'd definitely consider it for new projects. The nice thing about Hasura is you have full access to the underlying Postgres DB. We are actually writing SQL for most of our data fetching needs with a traditional express backend. We're only going through Hasura when we need realtime capabilities. But it's pretty nice to be a bolt it on and get subscriptions out of the box :)
It's the same for supabase without the additional graphql layer. It runs a separate elixir project to convert postgres changes into real time subscriptions. You can use this without using other parts.
An architecture I've seen work is to have reads be direct from the client, but writes be through cloud functions. You can then do migrations and denormalization in the functions and the client sees the sync events as the write completes.
I do wish they'd add actual migration support though. Firebase has always needed some kind of document views like feature to allow backwards compat, but still allow changing the schema.
I don't understand why people are so keen on these "serverless" architectures. Why not just run a backend web server. It's generally the least troublesome part of the system, and it buys you a bootload of flexibility.
- Lack of schema makes it really easy write bad data without realising it. I inherited a 3 year old firebase/firestore codebase and database was FULL of inconsistent data. This was not helped by our application being in JavaScript meaning bad data could roundtrip all the way through our without triggering any errors. Only later causing obscure and hard to debug issues.
- Lack of query flexibility or joins make some use cases either impossible or very inefficient
- Connecting directly from client apps makes it very difficult to make backwards compatible changes. You can fix this by making everything go through backend APIs, but then you lose realtime which is the main benefit of firestore in the first place.
We're halfway through a port to Postgres+Hasura, and our app is much more reliable and responsive now.