Dear Firebase Team...
Tags: firebase, firestore, database, nosql
Published: 2021-05-23 19:36:41

This article is out-of-date. See my latest Firebase article for 2023:

https://code.build/p/VCg7fQ3GAwbrqWmqgaXMec/awesome-firebase-ideas-for-2023
___

**UPDATE:** 10/26/22 - Firebase Finally added a counter function! See [my latest article](https://code.build/p/DTqqs4noGR2quHjRhz8Vye/firestore-finally-solved-the-counter-problem-almost) on this.
___

Dear Firebase Team,

I speak for all of us avid users of your wonderful product Firestore. While we are happy you are working diligently on all your  Firebase products, you are losing your Firestore users, and you need to start listening to them.

The last meaningful update you gave to Firestore was the "not equals" where modifier. This was excellent.  However, this was back in October 2020.  Watching videos called **What's New in Firebase**, and we don't see one new Firestore feature, is click bait and misleading.  Where is the Firestore team?

`Stop trying to fix internal problems, with Firestore Functions and External Packages!`

Here are the top current problems that need to be solved that will please 99% your users:

1.) [Geoqueries](https://firebase.google.com/docs/firestore/solutions/geoqueries) - A package, really? Didn't you promise somewhere this would be fixed?

2.) [Fuzzy Full Text Search](https://firebase.google.com/docs/firestore/solutions/search) - Your recommended solution from the worlds number one search engine is an outside search solution that is overly expensive? This can be done within Firestore. I know, I wrote 3 different ways to accomplish this in my [adv-firestore-functions](https://code.build/p/5XSkVJhq5BpEUuKPfzkJXU/which-full-text-search-index-do-i-use) package. How about you fix this internally with an index? Again, no more firebase functions to solve internal problems...

3.) [Counters](https://firebase.google.com/products/extensions/firestore-counter) - I understand counters are a complicated thing. Your argument for not doing that has always been scaling problems and speed. Well I counter (not pun intended) both those arguments with this:
- Firestore Functions can now work in the background for counters, whether it uses sharding, Algolia, or just basic document editing. However, I have mistyped one line of code in an updated firebase function, and my counting was off. Basically, other databases do it, and you have written external ways to fix it. How about automating this internally?  Your company probably employees the smartest database programmers in the world. Make it happen! This includes automatic counting of any query, or just the total number of documents in a collection. MongoDB has no problem with this. I have also written ways to make this work with **Collection Counters, Query Counters, and Condition Counters** in my [adv-firestore-functions](https://www.npmjs.com/package/adv-firestore-functions#counters) package.

4.) [Many-to-Many Indexes](https://stackoverflow.com/questions/46979375/firestore-how-to-structure-a-feed-and-follow-system) - We get that Firestore is a noSQL database not meant for complex relations. However, there is one particular type of many-to-many relationship that we cannot do in Firestore: a follower feed. This is something that is needed in many apps. There is currently no scalable way to model and query this:

```SELECT * posts WHERE users/followers == $userId ORDER BY createdAt DESC```

a) We need to allow complex indexes that optimize for reading (since it is noSQL) like [MongoDB](https://docs.mongodb.com/manual/core/index-intersection/#:~:text=MongoDB%20can%20use%20the%20intersection,intersections%20to%20resolve%20a%20query). Again, this index should be automatic and not use Firestore Functions. That way we could have an index like so:

```
docId: 2ls3ls,
follower: user123,
postId: 38280921
createdAt: 01-01-2021
```
And we could search for a follower feed... or:

b) **Google should create it's own Algolia that allows joins!** - This could also solve all four problems, but I digress.

5.) (Honorable Mention) - [Paging](https://firebase.google.com/docs/firestore/query-data/query-cursors) - I really can't go to the x'th document in a query like in `offset` without writing some code that reads every single document that comes before hand? There is a type of **B-Tree** in computer science called [Order Statistic Tree](https://en.wikipedia.org/wiki/Order_statistic_tree). Firebase Team, let's use this internally to index our document orders shall we?

Let's create the best noSQL product in the world. Let's not leave it in the dust. Firestore is winning with its easy of use product for those without server setup experience. However, here is your up-and-coming competition:

- [Cloud DGraph](https://cloud.dgraph.io/) - While it is not where it will be in just one year from now, the team here is listening to its users and working on powerful new features every day. This is by far my favorite and uses GraphQL on a graph database.
- [FaunaDB](https://fauna.com) - Not sure the internal workings, but it seems to be a highly modified noSQL document db that is  relational... very unique and powerful. This is my #2, except like firebase, you can't run it on your server.
- [NHost.io](https://nhost.io) - Built on Hasura, this postgresSQL uses GraphQl and requires little to no set up. (Tied for number 2)
- [Supabase](https://supabase.io/database) - another postgresSQL alternative
- [Couchbase Cloud](https://couchbase.com) - noSQL alternative
- [Appwrite.io](https://appwrite.io) - noSQL based on a Rest API
- [PlanetScale](https://planetscale.com) - seems to be in a beta, but some sort of SQL that scales...

So, let's give the users what they want, because IMHO Firebase (meaning Firestore, not all the other products bundled together) will always have a place in my heart... until it doesn't...

J