DEV Community

loading...
Cover image for Dear Firebase Team...

Dear Firebase Team...

Jonathan Gamble
・4 min read

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 - A package, really? Didn't you promise somewhere this would be fixed?

2.) Fuzzy Full Text 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 package. How about you fix this internally with an index? Again, no more firebase functions to solve internal problems...

3.) Counters - 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 package.

4.) Many-to-Many Indexes - 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. 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
Enter fullscreen mode Exit fullscreen mode

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 - 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. 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 - 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 - 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 - Built on Hasura, this postgresSQL uses GraphQl and requires little to no set up. (Tied for number 2)
  • Supabase - another postgresSQL alternative
  • Couchbase Cloud - noSQL alternative
  • Appwrite.io - noSQL based on a Rest API
  • PlanetScale - 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

Discussion (2)

Collapse
morenomdz profile image
MorenoMdz

Great info here, adding to the list:

  • Backups The current way of managing Firestore backups via gc is too complex and limited, for example, I can create a cloud function that will make a daily backup, but I cannot generate a download URL as Firebase Storage won't let me share whole folders (no zip for example), only individual files. So if I need to create a system backup that will save items images saved in the storage plus the db backup files, I will have to iterate over thousands of files to do it. This should be something much simpler via the SDK itself.
Collapse
100lvlmaster profile image
Navin Kodag

This might sound like pushing it. But being able to export your database would be nice.