Why you should not choose Firestore for your next project. Thread. #AndroidDev

0. Why could one choose Firestore? I don't know, that was not my decision. NoSQL storages typically have fascinating performance under certain kinds of loads, while default choice is one of SQL RDBMSs, which are modern, scalable, powerful, and fast for typical projects.

1. No joins. You can do it yourself and achieve N+1 problem, but things are gonna get worse when you try to.

1.1. IN condition receives max. 10 items. This means that you have to either limit foreign key count to ten or make several separate requests for a hand-rolled join. N+1 turns out to be N+M.

1.2. Maybe you've just done documents.mapTo(ArraySet()) { it.get("foreignKey", DocumentReference:: http://class.java )!! } for a join but IN argument must be a List in Java API. So you take a Set from the tweet above, allocate an ArrayList, and copy some pointers uselessly.

1.3. whereIn(…, vararg) overload also does not exist.

2. IN condition accepts only Strings and DocumentReferences. Wanna query unassigned + your own tasks? .whereIn("assigneeRef", listOf(null, me)) won't work, nulls are not permitted.
Of course, parameter types do not say anything about it. There are only runtime checks.

3. DocumentReference is a (Firestore, DocumentKey) tuple, and DocumentKey is a wrapper around ResourcePath which is actually a List<String> of “path segments”. Complexity hell for a human, and pointer hell for a CPU.

4. No OR conditions. No !=. There are lots of stupid limitations which lead to even more requests. https://firebase.google.com/docs/firestore/query-data/queries#query_limitations

5. You can get into DocumentSnapshot at arbitrary depth with keys of FieldPath type. So there is a type for key. But such a key is untyped.
Okay, pain with Bundles, Intents, SharedPreferences was not enough to learn the lesson.

6. Your vendor-locked storage (accessed via proprietary SDK) is now an interface for your mobile app.
Wanna move to PostgreSQL? Me too. You must hide Firestore behind a proxy server first, rewrite apps, and migrate storage after that.

7. Some queries can be done only with indices. Logic doesn't work here: x=a — ok, x=b — ok, x in [a, b] — oh no, create an index please! It's extremely inconvenient that indices created during development must be re-created for your production database.

8. When zipping two observable queries, a transaction could change data atomically, but you're gonna get two separate callbacks. Between them, you're gonna zip stale data from one query with fresh data from another query.

9. The data is already parsed. Whole numbers are longs. But I don't need to order more than 2 147 483 647 pizzas! Okay, i can doc.getLong("blah").toInt(), but what about doc.get("blah") as Map<String, Long>?

10. Just met a guy asking for help with Firestore on Telegram. Why your problem happens? What's the cause? I don't have any fucking clue. No publicly available source code; the community mostly consists of rookies who never used any databases before.

11. <sarcasm>Thanks for saying what type there actually was.</sarcasm>

12. Thanks, this shit identifies my document uniquely: 𝚌𝚘𝚖.𝚐𝚘𝚘𝚐𝚕𝚎.𝚏𝚒𝚛𝚎𝚋𝚊𝚜𝚎.𝚏𝚒𝚛𝚎𝚜𝚝𝚘𝚛𝚎.𝙳𝚘𝚌𝚞𝚖𝚎𝚗𝚝𝚁𝚎𝚏𝚎𝚛𝚎𝚗𝚌𝚎@𝟽𝟽𝚋𝚍𝚋𝟿𝟺𝟺