Home
> Firebase Wish List

Firebase Wish List

8 min read
Jonathan Gamble

jdgamble555 on Sunday, March 24, 2024 (last modified on Sunday, March 24, 2024)

I love Firebase. I truly think no other cloud database platform can compete with it. However, I have been frustrated with Cloud Firestore from Day 1. I came from an SQL background and couldn't believe you couldn't just do joins. Now I know how much more powerful MongoDB is, so it is not a NoSQL problem. Even though Firestore has come a long way since it was created, I believe there are some major features it needs to implement. There are also a few minor ones that would make things easy.

1. Offset#

Firestore finally gave us the count function. Since aggregations can be calculated on the server, I believe adding the offset() directive on the server side would be incredibly easy. This could probably be implemented, tested, and launched within a week. This would add better pagination, the ability to skip queries based on a number, better chats, forums, etc. This is a no-brainer to me.

2. Automatic Reference Aggregations#

After seeing how easy TTL (Time to Live) Policy is to use from a user experience perspective, it would be cool to see the same thing work with reference types. Imagine a Reference Type field doing automatic aggregations.

Collection Group

posts/e4612b59-e049-4801-89a1-82d0fff8e575/cmxhndjserxsllrvfb6ean38h.jpg

Now, you select the collection you want to trigger and the reference field in that collection. Whenever that reference field's target gets updated, it will automatically be added to the document as an aggregation.

One-to-One Reference#

So, for example, an author reference field in a posts document could be automatically aggregated so that the posts document always contains the up-to-date author document inside it. This basically simulates inner joins for documents.

Perhaps under the hood, it would need to create an onWrite event trigger on the posts collection to create the original document aggregation as well as an onWrite trigger on the users collection to update the document aggregation when a user updates their data. However, it would be much safer if this could be done automatically with Firestore on the backend.

Nested One-to-One-to-One#

This could also cover cases where nested documents reference other documents; however, you would want strict size limits.

Reference Aggregation Index#

Another similar option would be to store caches of the actual referenced document so that when Firestore queries the document, the data would automatically be there. The referenced data would not be editable, as it would really just be a one-to-one document reference cache. Editing the original document would automatically update the cached reference as an index.

Advanced#

There is another case, particularly for many-to-many cases or the Follower Feed, where you may want to copy entire documents inside other documents. Imagine having a posts collection, and you want to copy each post document inside a users/{userID}/followers collection. This would make creating semi-complex aggregations like this easy.

If you want to search for any text in Firestore, you must use an external database and sync it. This is probably the second most requested feature. You can read about my full-text search post.

Issue Trackers#

4. Remove NodeJS Dependencies#

Right now, firebase-admin can only work in NodeJS environments. This means it does not work in Edge Functions on Vercel or Cloudflare. However, it should be able to work in any secure JavaScript environment.

Server Firebase Authentication#

It is also a problem that you can’t authenticate with Firebase Client SDK on the server. You have to pass the authentication data from the client to the server. See SvelteKit Todo App with Firebase Admin. This causes a lot of compilation problems. I should be able to use authentication on the server side as well.

5. Edge Cloud Functions#

Not only would this fix the problem where firebase-admin is not available on Edge Functions, but it would also be way faster. Cloud Functions just released Generation 2, but Generation 3 doesn't sound so bad. They would have to have firebase-admin availability, so this would be extremely fast and would have no cold start times!

6. array-contains-all#

There should be a way to filter arrays when you need the AND clause. I understand this limit was set on purpose due to speed issues. However, putting limits on this would give Firestore greater flexibility, which is much needed. This would also solve the problem of limiting one array-contains per query. We need more powerful queries. Find a way.

Issue Trackers#

I'm excited to see what the team comes up with as long as they keep innovating with new features for Firestore.


Related Posts

🔥 Authentication

🔥 Counting Documents

🔥 Data Modeling

🔥 Framework Setup

🔥Under Construction

© 2024 Code.Build