> … it's not possible to export your users data. You can't export emails, password hashes.
Could someone provide details on email/password export from Firebase? This limitation seems very critical.
Could someone provide details on email/password export from Firebase? This limitation seems very critical.
In general most of OP's complaints are inaccurate- it sounds like they just didn't fully read the docs before building their app.
Otherwise you can end up like Code Spaces, who lost their users' data and all their backups at the same time.
It's not documented, but apparently you can request the password hashes as well.
Firebase's querying methods are also severely limited. Yes, you can be smart about how you structure your data to overcome some of these limitations, but I've noticed that many db operations that are typically simple and inexpensive tend to require trickery and gymnastics with firebase.
I think my least favorite part of my experience with firebase has been the use of their security rules. First off, the "bolt" compiler is really bad, but necessary to avoid writing a huge mess of json. Often times, it compiles your security rules into a single line of json, and then checks for errors, giving you an unhelpful message that the compilation failed on line 1, column 32,513.
The security rules are not only cumbersome to write, and in a language you have to learn specifically for firebase, but also completely different when using the firebase database and firebase storage. For storage, you have a new language and new syntax to learn.
Moreover, it's pretty common that you'll update the schema for some object in the database and then be faced with a "Permission denied" error on all future writes. It's impossible to put the application into dev mode to get a more helpful error message saying which specific field the write failed on. And even with lots of tests, it is really scary deploying changes to the security rules to production in a way I just haven't felt using other dbs.
Come to think of it, that's not the worst part. For me, it's been their support. I really think they use some kind of generic answer bank to generate the bulk of their responses. Half the time the response doesn't even make sense in the context of the request I send. Something like "I'm getting X error message when I try Y using Z setup" will get a response like "Could you send a screenshot of the error message?" -- where the error message was copied and pasted verbatim into the original email. I suppose they hope I'll just give up after so much time wasted on the issue?
After using firebase for over a year, I'd wholeheartedly advise steering clear of it for anything other than prototypes and hackathon projects.
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) and 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), and Horizon has it's own rules templating system ( 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) 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/]), 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#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) 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.
1. Allow errors to be source mapped back to the language they were written in originally (bolt/blaze/json). Proper line numbers should be in the error messages, and if that's too much to ask for, then at least don't minify the JSON down to 1 line.
2. Bring back debug mode!
3. Make it possible to see, when changing a schema through the rules, what existing data that was writable will no longer be writable because it needs to be updated to match the new schema. (In dev mode, not so important. In production, this would be my number 1 concern.)
4. Stick to one language for all of the rules. I don't see any reason storage rules couldn't also use Bolt.
5. Allow imports. My rules file was getting long, so I eventually decided to split it logically and concatenate before compiling, but that's far from ideal.
6. Within the firebase console, allow us to see the details of incoming requests (including auth data) as they happen. And whether they're going to get a "Permission denied" error or not. It doesn't need to be a permanent log or anything like that, but maybe something you can enable for a few minutes while debugging. The simulator sort of helps, but it's so limited. There's nothing that compares to real logging when you're trying to figure out what's going wrong.
And as an aside, looking at the "legacy" docs again brings back good memories. I enjoyed firebase way more before the Google transition. In addition to having better support the docs were friendlier, and that made a big difference.
Literally took me 5 seconds of Googling.