4 ms·

> 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,

> 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.

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.