Hello everyone, we're on the Firebase team at Google, ask us anything!
Let's talk about:
We'll be answering your questions live from September 23rd, 8:30 am PDT / 3:30 pm GMT.
about a month ago or so, fireSQL was launched with limited queries allowed. my first inclination was that with this new possibilities/feature some SQL power will be present ; is there any plan to address the count thing for collection anytime soon?
Hello TeamFirebase,
My questions may be dump but will like to help me more on structuring:
The limitation for Index entries for each documents being 40,000 limits us with the number of fields we can have limitation on the number of fields we can have in a document, what should we do in that scenario?
Hey, folks! We gotta run; Wednesday is my "too many meetings" day, and I know Sam, Puf, and Peter had to run off to other meetings as well.
Thanks to everybody who asked us questions! Always good to see such enthusiasm from the Firebase community, and hopefully we can do this again sometime...
Thanks for this AMA.
Can you confirm that what is said in this Reddit thread is correct: reddit.com/r/Firebase/comments/ixx6f3/firebase_le…
Thanks!
Since compiling Dart to Javascript was one of the core design choices around the language. When are you guys planning to support Dart as an official Firebase Function language, finally allowing Flutter developers to build entire systems from one language.
Think this has probably been asked before, but I think it would drastically improve adoption of both Flutter and Firebase as a whole.
Firebase RTDB can experience an extended 100% load event, lasting upwards of 15-30 minutes during intensive use. While this is occurring, its operations per second drops considerably, resulting in a backup of pending tasks, and further exacerbating the issue.
Why is Firebase slowing down while at 100% load instead of continuing to operate at max capacity?
Having not used hashnode previously, I don't seem to be seeing any QA's
Am I missing something ?
Do you plan to support LinkedLists? In FireStore? Would be good for managing ordered lists and improve sorting.
In dealing with a firebase RTDB issue, where we experience frequent 100% load spikes, we have exhausted all the recommended debugging / resolutions strategies, including utilizing the profiler, Cloud Monitoring, DB sharding, query optimization, etc..
How can we scale firebase RTDB to meet our needs, or is it possible that we should migrate to another service? What are the hard limits on scalability for firebase?
Hello, Firebasers.
Firstly, I just wanted to say how much I love Firebase and how grateful I am that Google hasn't sent it to the infamous graveyard where other beloved Google products have sadly gone. I've been using Firebase almost exclusively for the last four-and-a-half years.
I apologise for being greedy, but I have a few questions. Hopefully nothing too complicated that stumps your brilliant minds.
Will there ever be a solution to the massive cold start issues with Firebase Functions? I realise they use Google Cloud Functions under-the-hood, but I've found unless I continually ping my functions to keep them warm, the startup time can be brutal.
Are there any plans to add a cron feature into the Firebase interface? I know you can create crons through Google Cloud, but integrating them into Firebase can be tedious. I would love to be able to trigger cloud functions, perform actions in Firestore (clean old orphan data) and whatnot from Firebase Crons.
GraphQL. Any plans to explore the possible use of GraphQL natively within Firebase? I've written GraphQL API's using Firebase Functions before, but I'd love to be able to map my Firestore database to a GraphQL layer of some kind without having to maintain it myself.
Will you consider adding in the ability to configure caching? Right now, querying data in Firestore (even if it hasn't changed) results in being charged a read. It would be awesome if I could configure a cache strategy (document-by-document basis, even better) where I can specify content is cached for X amount of time (30 minutes or something) and any reads of cached data would not be counted towards usage.
Any plans to introduce a non-NoSQL database option, something more akin to a traditional RDBMS like Postgres? Firestore is great, but it's not a perfect fit for all use-cases.
Will pricing around Firestore ever be improved? Cost-wise, Real-Time Database is more cost-effective than Firestore. Perhaps considering a model which considers the storage size used of your documents and overall Firestore instead of going so heavy on read and write cost would be worth considering.
Is there any plan that Firebase RTDB will be replaced by Firestore?
Here's a non-firebase question:
Impostor syndrome is one challenge developers face, what are your individual experiences with impostor syndrome, and what advice do you have for developers facing this currently?
Thanks for this AMA Frank, Samuel, Todd and Peter.
I don't use Firebase as much as I did in the past, how does Firebase fit into the current JAMstack ecosystem?
This question is regarding Firebase Rewrite for CloudRun and Architetcing Firebase hosting with cloud run region with Firestore region (while discussing with Cloud run developeres I got this) :
we understand that Firebase Hosting originates in us-central1 and CDN available across all regions, the problem is how to architect if we are based in India location
firebase hosting(locked to us-central1 ) +cloud run(which region we should select?)+Firestore(FB app created in MUMBAI (asia-south1))?
Question details:
Request path Scenario 1:
user/you(India)→India(CDN)→USA(Firebase us-central1)→ Singapore/Tokyo(CloudRun+aync call to Firestore India)→USA→CDN→you
which is REALLY BAD in terms of latency how to deal with it?
*I can't move or change / recreate my firebase app to us-central1 location.
1 possible solution is to use replace cloud run and build static sites by replacing firebase firestore SDK to cloud function with caching with a static site but we really need a SDK level firestore CDN solution to avoid this locked us-central1 firebase hosting us-central1 lock
another option is we need Firebase Hosting to originate in all 3 zones such that each zone have a separate firebase instance for using firebase hosting with rewrites to cloud run! otherwise cloud run users have to move to another local region hosting providers or move out of cloud run :(
Also cloud run SINGAPORE (asia-southeast1) region doesn't have rewrite access to firebase hosting please resolve this
Thanks you
Credits: @ahmetb for explaining Request path Scenario :)
Is geo-search for Firestore on the roadmap?
Next to full-text-search, geo-search is a requirement A LOT of apps have, and besides the added complexity of using a third party service (such as Algolia), they're also VERY expensive. Also, because of this not being integrated into the suite I've been fighting with race conditions a lot, using transactions to mirror my data from Firestore to Algolia - please do something about that! 🙏
Do you guys think about adding more searching functionalities to firebase storage, such as name or date quering?
What would be the best way show data from multiple projects on a single screen (eg. DAU, day 1 retention) ?
My questions:
Why is FCM so difficult to use? The token management logic needs to be written by the developer, which is fine but the APIs aren't very friendly to use. For example, the group notification APIs do not have a DELETE group API node till date, the way it works now as per the docs is that at least one token needs to be passed in order to create the group, and essentially when all tokens are removed the group deletes internally. This is bad design generally because let's say I'm coding a backend which has messaging lists so that I can send a notification to a group of users simply by sending to that list--I need to add a minimum 1 user with a valid token in order to even create that list and store it's reference for sending messages later, which is bad design. This is also bad because sometimes a developer may LOSE a token generated in the past and can then NEVER delete that group--I faced this when I was initially designing the backend was making test requests without storing the token and only later realised how FCM manages it so I have residual groups that I cannot delete even thou I have the group's reg ID. On top of that, despite creating the group, the token updates are still to be managed by the developer i.e. when a token expires that group continues to have that token despite expiry rather than it internally updating to whatever newer token was issued.
Why doesn’t firebase auth allow extra meta data by default? I understand there is a technique to set a flag marking a user's role internally using "custom claims" but this isn't the same as setting extra custom fields such as city or t-shirt size, etc. A developer needs to create a separate database collection for managing their users and there isn't even a way to mark a reference of the database entry to the authentication table so that I can jump from auth list to this user details entry, making it difficult. Plus the whole technique is kind of counter-intuitive since I now essentially have 2 user tables.
Combining points 1 and 2, it would be nice to see FCM token management done internally by the firebase auth libraries for various platforms... since when Firebase provides Auth and FCM why not the features where they work together as well? Would help SOOOO many developers if when using both Auth and FCM, the auth library automatically could take up the fresh token during authentication process and automatically update the token internally on token expiry too. This would make the self-managed FCM to firebase-managed making life easier for so many devs.
Why does GeoPoint datatype on Firebase Firestore suck? I am unable to do comparisons as it internally only compares the latitude value alone. There was literally an issue raised in the NodeJS SDK for firebase and the final solution was to avoid using GeoPoint altogether and custom write logic for GeoPoint comparisons or use Geohashes (again custom coded by developer).
I believe the above GeoPoint limitation exists because of the same query limitation—“Queries with range filters on multiple fields are not supported.”? Why do you have such a limitation on Firestore? Any commercial or large product will have to query multiple fields so forcing single field conditions renders firestore not viable for production-level apps. Am I right?
Is there any easy way to profile firestore writes/reads? At leases get a breakdown by collections?
How to minimize document reads in a collection if you have frequent multi item searches?
What are some new features that you're working on? Can you spoil some of them for us?
Jeff Huleatt
I work on 🔥 Firebase at Google
Saša Šijak
Do you have plans to improve firebase-web-ui UX? It has a very confusing UX and it is not configurable that much. There are a lot of issues in Github which are not resolved for a very long time.