3 ms·

I enjoyed reading this having battled with firebase on a personal project. It has just enough quirks that I now prefer postgres unless I need all of the firebas

I enjoyed reading this having battled with firebase on a personal project. It has just enough quirks that I now prefer postgres unless I need all of the firebase features desperately. > It seems that GCP is cannibalizing the Firebase developer environment. Yeah as a latecomer I got this impression and rolled my eyes. I imagined a debate in the office between an passionate Firebase OG and a Google exec holding an OKR portfolio, the passionate engineer trying to delay the inevitable gobbling up of firebase! For me Firebase has lot of cuts, maybe not 1000 but things like: * No formal definition of rules, just some very scant documentation. Much of it is undocumented or can only be found in SO answers. * Emulator fatigue! Like Azure storage, the emulator is a good approximation to the real thing but you end up chasing down bugs locally when it is an emulator quirk. Postgres OTOH you run the same thing in prod. Same for mongodb, mssql, mysql etc. * Firebase admin sdk has a completely different API to the normal sdk to do all the same things! I get it: smaller JS bundles, but why not just reuse a lot of those changes in admin? * You have to have a local file with authentication secrets to a cloud db in order to run the emulator! I just have a test deployment for this but it feels unnecessary. * I don’t think the model of letting users upload json directly to collections is secure- unless you are a genius with firebase rules. This might be more of a general criticism of nosql over http. CouchDB might have the same issues I guess. * Rules bugs like if you do a query with clauses your rules don’t have access to the entire object just the queried fields. You need to add ghost fields to the query to make the rule run properly. Probably more things I forgot about too. I am even tempted to reverse engineer rules to write a proper guide. If that sounds interesting let me know. Finally I prefer open source stuff for a lot of the usual reasons. So closed source stuff has to be beyond excellent to make sense to me to use.

asciimike 4y ago
> I am even tempted to reverse engineer rules to write a proper guide. If that sounds interesting let me know. No need to reverse engineer them, I built them, so I'm happy to answer any questions you may have (to the best of my memory). > * I don’t think the model of letting users upload json directly to collections is secure- unless you are a genius with firebase rules. This might be more of a general criticism of nosql over http. CouchDB might have the same issues I guess. It's a general criticism of any "access your database/storage bucket/etc. directly from the client" product--everyone has to build _some_ authZ mechanism that lives in between the client and the server, whether it's Firebase Rules, Postgres Row Level ACLs, Lambda Authorizers, etc. Otherwise you're writing your own authZ code on your own server, which has it's own set of issues. > * No formal definition of rules, just some very scant documentation. Much of it is undocumented or can only be found in SO answers. I don't think https://firebase.google.com/docs/rules https://firebase.google.com/docs/rules is the best documentation ever, but I'm not sure "scant" is the word I'd use to describe it. What are the main areas you think are missing?
- quickthrower2 4y ago
  > No need to reverse engineer them, I built them, so I'm happy to answer any questions you may have (to the best of my memory). What I think is needed is a definitive guide that approaches all the angles: * Beginner intro * Cookbook * Full docs * Data architecture tips * Limits of rules and when to use a function instead Having to ask questions is the annoying thing. Because it is a blocking affect on your flow as a developer. I found that your team has gone to great lengths to help people online answer their questions. But the DX of having a great reference guide would be nice. Then surface area of firebase being so big I feel like this might be seperate from the Google firebase docs that cover a lot of stuff already.
combyn8tor 4y ago
I always thought a rules "learning" mode in the emulator would be useful. While the mode is switched on, the rules are set to allow read/write everywhere. Run your app and simulate a typical end user interaction. After you're done, the learning mode writes a set of the most restrictive rules possible based on the data read/writes from the simulated interaction. I think this would make a good starting point for new apps.
- quickthrower2 4y ago
  It would be good. However security has to be thought about alot I don’t think AI is there yet.
  - combyn8tor 4y ago
    I don't think it's a case for ML.

asciimike 4y ago

> I am even tempted to reverse engineer rules to write a proper guide. If that sounds interesting let me know. No need to reverse engineer them, I built them, so I'm happy to answer any questions you may have (to the best of my memory). > * I don’t think the model of letting users upload json directly to collections is secure- unless you are a genius with firebase rules. This might be more of a general criticism of nosql over http. CouchDB might have the same issues I guess. It's a general criticism of any "access your database/storage bucket/etc. directly from the client" product--everyone has to build _some_ authZ mechanism that lives in between the client and the server, whether it's Firebase Rules, Postgres Row Level ACLs, Lambda Authorizers, etc. Otherwise you're writing your own authZ code on your own server, which has it's own set of issues. > * No formal definition of rules, just some very scant documentation. Much of it is undocumented or can only be found in SO answers. I don't think https://firebase.google.com/docs/rules https://firebase.google.com/docs/rules is the best documentation ever, but I'm not sure "scant" is the word I'd use to describe it. What are the main areas you think are missing?

quickthrower2 4y ago
> No need to reverse engineer them, I built them, so I'm happy to answer any questions you may have (to the best of my memory). What I think is needed is a definitive guide that approaches all the angles: * Beginner intro * Cookbook * Full docs * Data architecture tips * Limits of rules and when to use a function instead Having to ask questions is the annoying thing. Because it is a blocking affect on your flow as a developer. I found that your team has gone to great lengths to help people online answer their questions. But the DX of having a great reference guide would be nice. Then surface area of firebase being so big I feel like this might be seperate from the Google firebase docs that cover a lot of stuff already.

combyn8tor 4y ago

I always thought a rules "learning" mode in the emulator would be useful. While the mode is switched on, the rules are set to allow read/write everywhere. Run your app and simulate a typical end user interaction. After you're done, the learning mode writes a set of the most restrictive rules possible based on the data read/writes from the simulated interaction. I think this would make a good starting point for new apps.

quickthrower2 4y ago
It would be good. However security has to be thought about alot I don’t think AI is there yet.
- combyn8tor 4y ago
  I don't think it's a case for ML.