I'd love some more feedback on the Rules (disclosure, I'm an engineer on that team). JSON was originally picked since it felt closely aligned with Firebase (JS

I'd love some more feedback on the Rules (disclosure, I'm an engineer on that team). JSON was originally picked since it felt closely aligned with Firebase (JSON data => JSON rules), but as we started building more into them (indices, etc.), and as people started writing more complex rules (even internally), things started getting really clunky. Blaze (https://github.com/firebase/blaze_compiler https://github.com/firebase/blaze_compiler) and Bolt (https://github.com/firebase/bolt https://github.com/firebase/bolt) were attempts to 1) add a less verbose syntax to rules, 2) add new features that promote code reuse (like functions), and 3) get feedback on the direction developers would like to see our authorization product move. The new Firebase Storage Security Rules are the next iteration of that. They provide a non-JSON (though unfortunately non-standard) DSL with strong types, more functionality, functions, and some other cool things (like giving you actual row/col numbers for failures). We think it's an improvement on the JSON rules, but still think there's a lot left to do. Resolving the difference between the two languages is one of my goals, and I'm looking in to what it would take to update the Database to handle the Storage rules language so there's consistency across products. Unfortunately, when it comes to building a custom DSL, it's hard to pick some standard. Parse has user ACLs (PFACL, PFRole on iOS for instance: https://parseplatform.github.io/docs/ios/guide/#roles https://parseplatform.github.io/docs/ios/guide/#roles), and Horizon has it's own rules templating system ( http://horizon.io/docs/permissions/ http://horizon.io/docs/permissions/), but I don't think there's a good standard out there. We picked XACML (https://en.wikipedia.org/wiki/XACML https://en.wikipedia.org/wiki/XACML) as the basis for Storage Security Rules, but any other feedback on this would be much appreciated. We've considered non-code ways of doing this (like Blockly [https://developers.google.com/blockly/] https://developers.google.com/blockly/]), but don't have any concrete plans around those. As for verbose debug info, we used to support a "debug" parameter in our tokens (https://www.firebase.com/docs/web/guide/login/custom.html#section-tokens-without-helpers https://www.firebase.com/docs/web/guide/login/custom.html#se...) which would return the rule that failed (basically the output of the simulator, which told you exactly what happened where). I'm looking into adding that back, since I agree that it's pretty useful. If you haven't seen the database Security Rules Simulator (which shows this info) you should definitely check it out. Targaryen (https://github.com/goldibex/targaryen https://github.com/goldibex/targaryen) is a similar concept that you might like (unfortunately only works on the database). As for your second comment on support. The short answer is that I agree with you--since acquisition (and post I/O in particular), support has suffered (in terms of measurable things like response time as well as intangibles like response quality). I think there are a few reasons for this: 1. As a startup, you should optimize for an amazing support experience since at the expense of scalability. Everyone at Firebase was on a support rotation, and if customers had issues with the product, they talked directly with the engineer who built it and provided direct feedback and had their issue answered. It was a tradeoff (products were built slower), but it was incredibly important to is (engineers knew how the product was being used). Now that we're more than just the original Firebase features, it's much harder to have every engineer doing support, and it's actually much less valuable to have them doing this now. A lot of the value of engineers triaging front line support for a more mature product has been removed--many of the cases we get are "RTFM" plain and simple, or the error message sent tells you exactly what the problem is (or there's a stack overflow post that details the exact problem that we've already answered). When cases get interesting, they get escalated to the engineer who built the feature. It's the people equivalent of load balancing, but unfortunately the routing isn't perfect ;) Which is a great seque to the other half of the problem... 2. Unlike technology, scaling people based processes turns out to be really hard. Technology usually scales horizontally pretty easily, people don't. You can provision new machines in minutes, but training people takes years. We've spent a lot of time teaching our new support team what Firebase is, how Firebase is generally used, and what problems people run into. We've built playbooks for each feature, created canned responses, and generally tried to build infrastructure to make knowledge available as best we can. I don't claim that these things have solved the problem, as when you're constantly working on new features, that also means the knowledge created and processes put in place have to be passed down to all of those locations. With any documentation or institutional knowledge, it's hard to ensure everything is up to date and people are all on the same page. That said, the base line of "not asking for an error when the error is right there" is occasionally not there, and I'm working with the support team leads to combat this (as well as generally improve the experience). If I could wave a magic wand and change one thing about our current support it would be for people to adopt a distinct personality vs a script based system--even if they ask a dumb question and admit it, it's better than following a script and sounding tone deaf. If you could wave a magic wand and change one thing, what would you change? Feel free to email me mcdonald at firebase dot com (or answer here), I'd love to hear feedback on rules, support, or Firebase in general.