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.

Issue Trackers#

• Offset

2. Automatic Joins#

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.

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.

Issue Trackers#

• DocumentReference join query

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.

3. Full Text Search#

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#

• Allow regex queries
• Add text search to realtime database
• Search Collections in Firestore by field values
• Native full text search similar to Algolia/ElasticSearch

4. Firestore Admin Lite#

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. You can use the Firestore Lite package to handle REST API calls, but there is no way to handle authentication on the server without firebase-admin.

Firestore Auth Lite#

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 without the need for firebase-admin. Needing admin functionality and basic authentication on the server should not require different packages.

Issue Trackers#

• Firebase Admin Lite
• Admin Version of Firestore Lite

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#

• Firestore support for array-contains all
• Array contains all operation

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