My Firebase Wish List

It's the holiday season. Time to draft wish lists. In this case, for some amazing features that would oh-so-much improve the jolly Firebase services. 🤞

So, here goes, in no particular order:

Partial string matching in Firestore queries

I wish Firestore would allow to query documents where a field (of type Text string) contains a given query string. Something like where('fieldName', 'contains', 'queryString'). I won't even ask for fuzzy matching or wildcards. Just exact substring matching would open up so many additional use-cases for Firestore. Existing workarounds for this long-standing feature-request are limited to prefix-matching, unfortunately.

Field-level diffs when when listening to document updates

I wish the Firestore SDKs would inform me about which parts of a subscribed-to document or documents were updated in the onSnapshot method. For snapshots on queries, the SDK already exposes whether documents as a whole were added, modified, or removed. However, I am further interested in field-level diffs. They would allow, for example, to update only parts of a UI backed by a Firestore document. This could open up interesting opportunities to use Firestore to build real-time collaborative forms.

Resolving Firestore reference data types in a single query

I wish Firestore would allow queries to resolve references to other documents. I know this wish may be far-fetched. It's basically asking that Firestore introduces some form of joins. But maybe it could be possible with some restrictions, like limiting the number of documents to resolve this way, or only allowing this feature when the "root" query targets a single document? Maybe?

It's quite tantalizing that there is a reference data type, but one still has to manually construct any joins from the client.

Allow to configure i18n rewrites in hosting

Firebase hosting supports configuring i18n rewrites, where users are served localized versions of a page based on their ' Accept-Language headers. As a result of relying on rewrites, though, all localized versions of a page are served from the same URL. This makes it impossible to share language-specific links, and goes against Google's own recommendations for providing multilingual sites.

Configure hosting to serve files from Cloud Storage

I wish I could configure Firebase Hosting to serve files from Cloud Storage. Doing so could, for example, be based on rewrites that target a bucket and path within it. When targeting a folder, hosting would by default attempt to serve an index.html file within it. Wildcards (i.e., **) could be used to serve files matching any given URL dynamically (i.e., allowing at runtime to store files in a bucket and make them available via hosting). An optional fallback could allow to define what file to serve if a (dynamically targeted) file cannot be found. Here a made-up configuration example:

1
"hosting": {
2
  // ...
3
  "rewrites": [ {
4
    "source": "/products/**",
5
    "hosting": {
6
      "bucket": "gs://my-custom-product-bucket",
7
      "path": "/products",
8
      "fallback": "/404.html"
9
  } ]
10
}

In the above example, a request to /products/awesome-swag results in the file located at gs://my-custom-product-bucket/products/awesome-swag.html being served. If that file doesn't exist (or isn't publicly accessible), /404.html (located natively in Firebase Hosting) is served as a fallback.

There are always things to wish for in the services one uses. For example, I already wished for three Firebase features in a Tweet in January.

And lo and behold: two of the three wishes I stated back then have actually been addressed! For one, Firebase recently announced significantly improved support for Next.js. Furthermore, Google is about to release an update that would drastically decrease execution times of Cloud functions that use Firestore.

I am very grateful for the folks at Firebase pushing these improvements. Some wishes come true, after all! 🎊