Specifically, complaints 2-4 sound like they all arose from nesting all of your data in one tree[1] and using a query for all children[2]. This means you'll load too much data in every request, which will slow down your microservices and cause a large bill for unnecessary outbound traffic.
#5 has two possible solutions. Either use the push() message to avoid any conflicts in the data you're writing or the transaction() method to manage the conflicts in an online-only mode. push() requires some work to recompose something from a series of changes, but has the advantage of being offline-compatible.
Regarding #6, I agree we can better support data migrations (we're looking into it). If your problem is as simple as the one listed, I'd really recommend checking out a library like lodash[3]. The ugly if statement could have been
if(_.has(user, 'new_subdocument.new_property')) { /* do stuff */ }
or even:
var thing = _.get(user, 'new_subdocument.new_property', default); // always do something with thing; we just added an in-memory // value that we would have made a data migration for in the // past.
Finally, regarding queues, are you referring to firebase-queue?[4] This is an open-sourced part of our internal infrastructure. There are currently 16 issues open, but they seem to be mostly feature requests. If you've found bugs we'd love some repo steps.
I hope that helps. We're always listening on firebase-talk@googlegroups.com, stackoverflow.com, and our slack channel.
[1]: For a great article, see https://firebase.googleblog.com/2013/04/denormalizing-your-d... or the general Firebase data layout guide at https://firebase.google.com/docs/database/web/structure-data [2]: Try using order + limitToFirst(N) https://firebase.google.com/docs/database/web/retrieve-data#... [3]: https://lodash.com/ [4]: https://github.com/firebase/firebase-queue