Firebase 2019 Wishlist

[Gary Chamberlain]

It’s hard to believe that it has been almost 3 years since I wrote my Firebase 2016 Wishlist in this group.  At that time Firebase was a pretty new addition to the Google Cloud and was missing some important features. Everything on that list can now be achieved with Firebase.

Here is my prioritized list of features that I would like to see added in 2019. There’s a theme across a few of these that web\pwa programming could get some more lovin’.

Accurate and Efficient Firestore Document Aggregation

Sometimes you need real counts of the number of documents that meet some criteria. It should be easy to run a report that tells you how many current customer documents you have, how many are of a particular type, or any other property.  I know it is tricky in a NoSQL world because of the architecture. I also know that you can use Firestore transactions and/or cloud function triggers to approximate this. However, both are not considered guaranteed as far as I know. If you aren’t guaranteed that the counts are correct then that isn’t good enough, and you are then forced to do a brute force count at least every-once-in-a-while.

I would like to be able to set up counters that describe what and how to count (e.g all documents in a collection that have some property set to whatever).  Creating one of those counters would do an initial sweep, which has the normal associated read costs. Then the system would automatically trigger updates for each document in that collection when it is created, updated or deleted.  The counter value would be guaranteed to be accurate and reading the counter value would be just a matter of reading one value. Perhaps the counters would be documents in a special <<counters>> collection.

Non-Experimental Web Offline Persistence.

The recent addition of multi-tab support is huge. Thank-you! Without caching, the download counts accrue way too quickly.  It’s great that there is support for this in newer versions of the most common browsers, but I’d like to see it not be ‘experimental.’ This is a critical feature and IMO it should be a priority to make it a standard feature, that doesn’t need to be opted in to.  With Edge moving over to Chromium (hehe) I hope to see that browser supported in 2019, too.

Hosting Wildcard Subdomains

Firebase hosting is great. It’s fast, easy to configure, and pretty flexible. The new support for multi-hosting is a really great feature, too.  I’d love to be able to configure a wildcard domain such as <anything>.mydomain.com and have it map to a folder that downloads an Angular-based PWA. The Angular app could then parse the domain and show different content. Imagine an app where customers have their own third-level domain.

Pricing Details (e.g. reads/writes/deletes counts, budgets, etc.) Right in the Firebase Console

Todd Kerpelman and crew did a great job explaining how to monitor pricing in the Get to Know Cloud Firestore #3 video.  Could this information be available in the Firebase Console instead, including some charts that show reads, writes, counts, storage, egress, costs etc. over time?

FireSQL

Firestore is really great. For some use cases, though, a SQL database is still the better way to go. I’d love to have an intrinsic, pay-for-what-you-use SQL solution in Firebase.  FireSQL has a nice ring to it. As of earlier this year, we can now access CloudSQL from Cloud Functions. However, it’s a bit clumsy and doesn’t scale automatically. You need to set up a configuration that is large enough for your needs. Plus, it isn’t in the Firebase Console.

Google’s Cloud Spanner technology can provide the standard benefits of SQL such as schemas, SQL syntax, strong consistency, but also support high availability and scalability.  Couldn’t this technology be used to back a kick-ass FireSQL offering?

Full-Text Search in Firestore

Commercial apps need to provide search capabilities.  It would be great if there was a built-in way to do this rather than leveraging a third party service or rolling something custom in Cloud SQL.

Crashlytics, Performance Monitoring, Analytics for Web

Sure, there’s the standard website Google Analytics. However, it feels like web developers are missing out with all this great technology only being made available to non-web apps.  Can some of these features be added for the web with a dashboard in the Firebase Console?

Cron Trigger for Functions

This was recently my biggest wish. However, with the recent launch of Cloud Scheduler, the pain has been reduced. Nevertheless, I’d still love to see a Firebase Scheduler that is integrated directly into the Firebase Console.

Email and SMS Triggers for Functions

Cloud Functions are amazing. The more ways to trigger them the better.

List View Instead of the Big Rects

This is a minor change, but something that is quite annoying.  It’s hard to work with the projects list in the console when there are lots of projects.  Those big rectangles are nice when there are only a few projects, but waste a lot of space when there are many.  Can you add a list view option, please?

Search for Auth Users in the Console

This is also a minor change, but something that is annoying. When searching for someone in the Authentication Users tab, we must enter a full, exact email address.  Can you add the ability to search full-text, or at least by domain?

LinkedIn Auth

Yup, this can be implemented with Cloud Functions. Would love to see it as a standard option, though.

Here’s hoping…

Happy New Year!!

Gary

[Samuel Stern]

Hi Gary,

I was very happy to read your 2016 wish list again and see that it's all mostly solved.  It's nice to see that, at least for you, we're moving in the right direction.  Let me see what I can tell you about your 2019 wishlist.  Although as a long-time Firebase developer you know that we really try not to make promises about the future.

Answers inline to the things I know about.  Hope someone will chime in on the rest.

- Sam

On Thu, Dec 6, 2018 at 7:46 PM Gary Chamberlain <ga...@pro.graphics> wrote:

It’s hard to believe that it has been almost 3 years since I wrote my Firebase 2016 Wishlist in this group.  At that time Firebase was a pretty new addition to the Google Cloud and was missing some important features. Everything on that list can now be achieved with Firebase.

Here is my prioritized list of features that I would like to see added in 2019. There’s a theme across a few of these that web\pwa programming could get some more lovin’.

Accurate and Efficient Firestore Document Aggregation

Sometimes you need real counts of the number of documents that meet some criteria. It should be easy to run a report that tells you how many current customer documents you have, how many are of a particular type, or any other property.  I know it is tricky in a NoSQL world because of the architecture. I also know that you can use Firestore transactions and/or cloud function triggers to approximate this. However, both are not considered guaranteed as far as I know. If you aren’t guaranteed that the counts are correct then that isn’t good enough, and you are then forced to do a brute force count at least every-once-in-a-while.

When Cloud Firestore exits Beta we will be able to provide "at least once" guarantees about Cloud Functions.  We are also adding support for numeric transform operations (think "add 1 to field x") that will make the transactions part of this easier.

Native aggregations as part of the service are not part of our plan at the moment. We'd like to have it, of course, but as you said it's at odds with the scalable architecture.

 

I would like to be able to set up counters that describe what and how to count (e.g all documents in a collection that have some property set to whatever).  Creating one of those counters would do an initial sweep, which has the normal associated read costs. Then the system would automatically trigger updates for each document in that collection when it is created, updated or deleted.  The counter value would be guaranteed to be accurate and reading the counter value would be just a matter of reading one value. Perhaps the counters would be documents in a special <<counters>> collection.

Non-Experimental Web Offline Persistence.

The recent addition of multi-tab support is huge. Thank-you! Without caching, the download counts accrue way too quickly.  It’s great that there is support for this in newer versions of the most common browsers, but I’d like to see it not be ‘experimental.’ This is a critical feature and IMO it should be a priority to make it a standard feature, that doesn’t need to be opted in to.  With Edge moving over to Chromium (hehe) I hope to see that browser supported in 2019, too.

Web offline won't be experimental forever, but it will probably always lag a bit behind Android/iOS offline in some areas due to the limitations of IndexedDB.  You don't have to worry about us dropping offline support, we view it as a priority as well.  The "experimental" tag reflects that on the web we can't (yet) recommend offline as the default choice for everyone.

 

Hosting Wildcard Subdomains

Firebase hosting is great. It’s fast, easy to configure, and pretty flexible. The new support for multi-hosting is a really great feature, too.  I’d love to be able to configure a wildcard domain such as <anything>.mydomain.com and have it map to a folder that downloads an Angular-based PWA. The Angular app could then parse the domain and show different content. Imagine an app where customers have their own third-level domain.

Pricing Details (e.g. reads/writes/deletes counts, budgets, etc.) Right in the Firebase Console

Todd Kerpelman and crew did a great job explaining how to monitor pricing in the Get to Know Cloud Firestore #3 video.  Could this information be available in the Firebase Console instead, including some charts that show reads, writes, counts, storage, egress, costs etc. over time?

This will happen.  We're still working on the exact form but you'll definitely get more usage/billing information in the Firebase console in the future.

 

FireSQL

Firestore is really great. For some use cases, though, a SQL database is still the better way to go. I’d love to have an intrinsic, pay-for-what-you-use SQL solution in Firebase.  FireSQL has a nice ring to it. As of earlier this year, we can now access CloudSQL from Cloud Functions. However, it’s a bit clumsy and doesn’t scale automatically. You need to set up a configuration that is large enough for your needs. Plus, it isn’t in the Firebase Console.

Google’s Cloud Spanner technology can provide the standard benefits of SQL such as schemas, SQL syntax, strong consistency, but also support high availability and scalability.  Couldn’t this technology be used to back a kick-ass FireSQL offering?

This is not on the Firestore roadmap.  While it might be possible to layer some SQL bits on top of Firestore, we think it's important that the Firestore SDKs reflect the structure and limitations of the underlying database to promote the right development patterns.

I think we all have dreams of a pay-as-you-go Cloud Spanner deployment with direct-client access and realtime support, but that's just a pipe dream for now :-)

 

Full-Text Search in Firestore

Commercial apps need to provide search capabilities.  It would be great if there was a built-in way to do this rather than leveraging a third party service or rolling something custom in Cloud SQL.

We are investigating this.  It's probably still far off, but we want to improve the experience here.

 

Crashlytics, Performance Monitoring, Analytics for Web

Sure, there’s the standard website Google Analytics. However, it feels like web developers are missing out with all this great technology only being made available to non-web apps.  Can some of these features be added for the web with a dashboard in the Firebase Console?

We want to bring as much of FIrebase to the web as possible. That's all I can say here for now.

 

Cron Trigger for Functions

This was recently my biggest wish. However, with the recent launch of Cloud Scheduler, the pain has been reduced. Nevertheless, I’d still love to see a Firebase Scheduler that is integrated directly into the Firebase Console.

We don't have plans to build our own scheduler, but we are considering ways to make the Cloud Scheduler + Functions pattern simpler to use.

 

Email and SMS Triggers for Functions

Cloud Functions are amazing. The more ways to trigger them the better.

List View Instead of the Big Rects

This is a minor change, but something that is quite annoying.  It’s hard to work with the projects list in the console when there are lots of projects.  Those big rectangles are nice when there are only a few projects, but waste a lot of space when there are many.  Can you add a list view option, please?

Search for Auth Users in the Console

This is also a minor change, but something that is annoying. When searching for someone in the Authentication Users tab, we must enter a full, exact email address.  Can you add the ability to search full-text, or at least by domain?

LinkedIn Auth

Yup, this can be implemented with Cloud Functions. Would love to see it as a standard option, though.

Here’s hoping…

Happy New Year!!

Gary

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/1d75f7d6-1ead-4fe1-8304-64a5c47a15bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gary Chamberlain]

Thanks for the comments, Sam!  Very exciting.

[Paul Ryan]

Hi Sam,

 

I don’t suppose you would comment on feature:  Delete User Properties in the console

 

?

 

Any clarity would be muchly appreciated.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/7395fd65-08e6-4a16-bec7-2163c62ffcd7%40googlegroups.com.

[Tyler Rockwood]

Hello Gary - 

Quick question for you regarding full text search: What exactly is your use-case for full text search and what functionality do you need? Full Text Search is a bit of a catch-all term for me. Do you need substring matching? Do you need full support for matching multiple terms?

-Tyler

[Gary Chamberlain]

I'd like the ability to drop a search input box into my app and then use that text with a firebase API which returns a weighted set of matching documents from a single collection.  Substring matching with compound search terms would be ideal but, honestly, I'd take whatever I could get.  An optimal solution would just work, a la Google Search magic.

I envision a solution that might look something like this...

Documents could have an optional search_hints map

search_hints: {

  text: "Text that is used by the search engine",

  text_fields: ['person.bio', 'address.street'],

  importance: // some numeric weight,

  changed: // some UTC date

}

A developer opts into the full-text search by adding an instance of this map to their documents.  I gave some example hint fields, but haven't thought too much about what optimal fields would be. I imagine Google engineers would come up with a better set.  I made a distinction between a text field with explicit indexable text, similar to Google Drive (https://developers.google.com/drive/api/v3/file) and a text_fields array that indicates which fields in the document should be used for indexable text.  Perhaps things like importance, changed date, etc., would be used to help with the weighting of the found items.

For any collection that has documents with search_hints, Firebase would create a special kind of index that returns a weighted set of matching documents.

[Kato Richardson]

Gary, thanks for sharing this! I remember your 2016 wishlist and the awesome discussions it sparked. Glad to see it coming around again. Also glad to hear we got a few things right!

I'd encourage others to contribute their wishlists here. Feedback is a major way that we course correct and prioritize work.

♡, Kato

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/e6db900a-b957-48b3-8d7e-ee7fed5716dd%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

[John Carroll]

I really, really appreciate that the firebase team took the time to reply to this email :)

I realize that project schedules are always subject to change, and that there are many reasons for not commenting on future plans, but it's very nice to get some idea of the firebase team's thoughts / goals.

If I were to add something to this wishlist, it would be a Firebase version of the excellent Microsoft Azure feedback portal. As a relative newcomer to Firebase, in general I like the service a lot. Obviously it's not perfect (no product is), but it's a solid foundation with a heavy emphasis on an excellent dev experience which I *really* appreciate. One of the most frustrating pieces of firebase though, is the lack of a roadmap or really much official information in the team's plans for the future (at least that I can find). The fact that pieces of the service are obviously incomplete (e.g. Firestore) and contain points of irritation (understandably so), makes my desire to call out feature requests stronger then it might ordinarily be.

I can accept if project priorities are such that feature X (which I want) isn't as important as feature Y (which I don't want), but it's incredibly frustrating when you're not sure if the team is even *aware* of feature X. I really appreciate the Microsoft Azure Feedback portal because, even if features aren't planned, at least I feel like developers (me) are being heard. When I see that a feature which I want has many fewer votes then a feature which I don't want, I'm more sympathetic to the idea that my feature shouldn't be a priority for the development team. Being able to vote on features, even when I know the development team is under no obligation to use that feedback, makes me feel better / gives me a greater sense of agency.

Anyway, I super appreciate this email thread and the response to it :).

My 2019 wish is for an official firebase feedback app, which people can use to request and vote on features (which the Firebase team would be under no obligation to follow).

Thanks!

John

[Jeremy Sistrunk]

My firebase 2019 Wishlist is short, but here goes:

Native geo hashing and GeoPoint support. I’d really like this sometime in the near future but as it goes, firestore can’t query with GeoPoint yet, that would be so awesome, if you could. 

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/02ecff5c-5ec9-478f-9304-25d82666c030%40googlegroups.com.

[Kamil Wojtczyk]

Same here, although I'd also add collection group queries in Firestore and lift inactive time limit on Firebase Functions to the wishlist. Thanks!

[Alan deLespinasse]

On Friday, December 7, 2018 at 12:45:59 PM UTC-5, Samuel Stern wrote:

Accurate and Efficient Firestore Document Aggregation

Sometimes you need real counts of the number of documents that meet some criteria. It should be easy to run a report that tells you how many current customer documents you have, how many are of a particular type, or any other property.  I know it is tricky in a NoSQL world because of the architecture. I also know that you can use Firestore transactions and/or cloud function triggers to approximate this. However, both are not considered guaranteed as far as I know. If you aren’t guaranteed that the counts are correct then that isn’t good enough, and you are then forced to do a brute force count at least every-once-in-a-while.

When Cloud Firestore exits Beta we will be able to provide "at least once" guarantees about Cloud Functions.  We are also adding support for numeric transform operations (think "add 1 to field x") that will make the transactions part of this easier.

Native aggregations as part of the service are not part of our plan at the moment. We'd like to have it, of course, but as you said it's at odds with the scalable architecture.

 

The numeric transform operations sound great if Cloud Functions had an "exactly once" guarantee (and I'm sure they're useful in other contexts), but it seems to me that, with "at least once", if you want to keep track of an exact count, you're going to have to jump through some kind of (expensive) hoops involving a transaction that  both increments a counter and stores some kind of per-document "counted" field. Is there a cheaper/simpler way to make the increment function idempotent?

I don't know the details of "it's at odds with the scalable architecture", but to me it implies that coming up with our own solutions will be difficult or impossible.

[Gary Chamberlain]

On Wednesday, December 12, 2018 at 5:57:01 PM UTC-5, Alan deLespinasse wrote:

The numeric transform operations sound great if Cloud Functions had an "exactly once" guarantee (and I'm sure they're useful in other contexts), but it seems to me that, with "at least once", if you want to keep track of an exact count, you're going to have to jump through some kind of (expensive) hoops involving a transaction that  both increments a counter and stores some kind of per-document "counted" field. Is there a cheaper/simpler way to make the increment function idempotent?

I don't know the details of "it's at odds with the scalable architecture", but to me it implies that coming up with our own solutions will be difficult or impossible.

Very good point, Alan.  I misread the "at least once" mention and was thinking "exactly once."    Sam, while what you described does appear to be beneficial, I'm not so sure it would solve for aggregation accuracy.  The architecture might require the accuracy to be 'eventual' but it still should be 100% and guaranteed.  It's either accurate or it's not.  This is still my #1 wish.

[Gary Chamberlain]

Here's one more:

Automated and scheduled backup of Cloud Firestore similar to the functionality in Cloud SQL, integrated into the Firebase Console.

[jm.ch...@dubsmash.com]

Hi Sam -

Just wondering, are there any plans to continue to improve Google Analytics for Apps/Firebase? More specifically, bringing the Google Analytics for Apps more in line with standard GA? I think there are some powerful GA features that would be very welcome (we use BigQuery but it's...difficult). So if I had a wish list of features that would substantially improve the value of the platform, I'd say...

• Cohort analysis (ability to see which events or features impact retention)
• Ability to setup Funnels with event parameters (i.e. screen_view = home)
• Behavior Flows to understand how users organically interact with the app (vs. having to manually set those up)

Look forward to hearing more about what's ahead for 2019 -

Thanks!

JM

On Friday, December 7, 2018 at 12:45:59 PM UTC-5, Samuel Stern wrote:

[Samuel Stern]

Hi JM,

We're definitely planning more improvements to Google Analytics for Firebase and the separation between it and "standard" Google Analytics should become smaller over time.  I can't comment on specific features though but I can say your requests are totally reasonable!  There are some things that are much harder to do with the GA4F event-based architecture than they were on the standard GA architecture though.

- Sam

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/dbd526bd-2dd6-4108-8b00-5ab7f26044f8%40googlegroups.com.

[jm.ch...@dubsmash.com]

Awesome, thanks for the response, Sam! Looking forward to seeing what comes next.

JM

[John Carroll]

Here's a pain point I didn't expect to run into: in the web platform, add support for sharing firebase authentication across subdomains.

A (very?) common pattern for SPA web applications is to have a separate application for authentication. For example, account.domain.com might handle authentication for app1.domain.com and app2.domain.com. I believe this is how Google itself handles authentication.

Currently firebase authentication doesn't support this scenario and users must log into (and, more problematically, log out of) app1.domain.com and app2.domain.com separately. See thread: https://groups.google.com/forum/#!starred/firebase-talk/LL4p41s4a4I

Especially when dealing with multiple domains that share branding as well as contain sensitive information, I can foresee a user expecting that logging out of app1.domain.com will log them out of app2.domain.com, when, in fact, it will not.

Thanks,

On Thursday, December 6, 2018 at 7:46:36 PM UTC-8, Gary Chamberlain wrote:

[Will Battel]

My one and only wish is better support for pagination for Firestore queries with snapshot listeners. Right now there is seemingly no way to do it without using getDocument instead of addSnapshotListener.

Hopefully this is something we can see as Firestore emerges from its beta, as it seems like a pretty essential feature for a flagship database.

I've found plenty of people looking for answers on this but none seem to be available currently.

References:

https://groups.google.com/d/msg/firebase-talk/L-maF89Hc9M/DgpFh809FQAJ

https://groups.google.com/d/msg/firebase-talk/EaIJ-SBzG9k/jk1RhrDvBAAJ

https://groups.google.com/d/msg/firebase-talk/0_NujAFJR5A/d2H8BSBxFQAJ

https://github.com/firebase/FirebaseUI-iOS/issues/550

https://stackoverflow.com/q/47182780/1500134

https://stackoverflow.com/q/54274703/1500134

[dominic....@kontron.com]

I had an issue with firebase recently where I basically broke my production Database, that got me thinking;

What about a switch allowing to toggle 'production mode' in Firebase that would change the color theme and (maybe) add extra verification to prevent some manipulation errors.

I posted it here if you guys want to show some love! 

Thanks!