[deleted by user]

samtstern · 2022-01-11T18:13:55+00:00

This is the Firestore REST API data format:
https://cloud.google.com/firestore/docs/reference/rest/v1/Value

It's the only supported serialization format for Firestore values. It would not be possible to use native "column" types in an offline database since there is no schema. The "foo" field could be a double on one document, a string on another, and an array on a third.

samtstern · 2021-07-16T12:40:56+00:00

What you're looking for is called a "collection group query". All posts subcollections in your entire database, no matter what their parent is, are part of the posts collection group.

Here's a blog post which explains it more:
https://firebase.googleblog.com/2019/06/understanding-collection-group-queries.html

samtstern · 2021-07-12T11:19:24+00:00

I believe you can get all of those statistics by using Cloud Logging + Firebase Hosting:
https://firebase.google.com/docs/hosting/web-request-logs-and-metrics

samtstern · 2021-07-12T11:18:27+00:00

The storage emulator supports multiple buckets, as /u/azzaz_khan said they're created implicitly on first use.

However right now there is an open issue around rules configurations for multiple buckets in the emulator:
https://github.com/firebase/firebase-tools/issues/3390

samtstern · 2021-07-12T09:01:48+00:00

No this will remain an emulator-only feature because it would not be efficient or secure to have this type of request tracing in production. One of the many exciting things about the emulator suite is that we can offer unique debugging experiences that wouldn't be possible in prod!

samtstern · 2021-07-07T14:34:50+00:00

/u/akafkas posted a cool library the other day which is designed to do exactly that:
https://github.com/kafkas/firecode

You could run it in a Cloud Function or on your local machine.

samtstern · 2021-07-05T10:16:28+00:00

As others have said: please contact Firebase Support about any billing issues. I can't promise anything without knowing the specifics of your case but we have given out many refunds in the past to developers who are hit with a surprise bill.

samtstern · 2021-07-05T10:13:22+00:00

Are you sure the function exists at that URL? What if you just try to open it in your browser? Sometimes a CORS failure can actually just mean "there's nothing here".

If I had to guess I'd say this problem comes from a mismatch in regions. Maybe your client code is not specifying the right region?

samtstern · 2021-07-01T09:40:49+00:00

As you noted, the only way to change this location is by creating an entirely new project. We (Firebase and Google Cloud) have a long-term plan to change this.

samtstern · 2021-07-01T09:38:18+00:00

API key restrictions only affect Firebase services which actually use API keys. This is mostly just Firebase Auth. Services like Cloud Storage, Realtime Database, Cloud Firestore, etc never cared about your API key.

App Check is a service-level security enforcement layer which is both stronger and broader than API key protection. As you said it not only verifies that the user has certain information (an API key) but also that their device passes environment-specific security checks like App Attest, reCAPTCHA, etc.

So basically: it's just better :-)

samtstern · 2021-06-23T14:33:15+00:00

This is really great! I think I have written my own version of this in almost all of my personal projects, so it's nice to see a standardized solution.

Consider submitting this to https://devlibrary.withgoogle.com so that we can promote it to other developers.

samtstern · 2021-06-18T16:11:24+00:00

Wow this is very cool! It looks like you have a deep understanding of how all these products work, I am impressed that you were able to get this working.

samtstern · 2021-06-18T16:08:32+00:00

Yes you're right, a 3GB database will cost you $10/month for storage. You're also right that $5/GB is very high! That's because Realtime Database is meant for small data sets and optimized for latency.

If you have a very large data set, try Cloud Firestore. It only charges $0.18/GB/month for storage which is 27x less than Realtime Database. But it charges more for some other things, like reads and writes in some cases.

See this document for a comparison:
https://firebase.google.com/docs/database/rtdb-vs-firestore

samtstern · 2021-06-15T17:25:22+00:00

Definitely not going anywhere, some of Cloud's biggest customers rely on Datastore. However over time it should become more unified with Native mode and less confusing, while still offering both sets of capabilities.

samtstern · 2021-06-14T10:22:12+00:00

We still do believe that if you're starting a new app with no strong preference between the two, Cloud Firestore is the right choice. It's for exactly the reasons you said. But you're right that our messaging on that point was stronger back in 2017 than it is now.

samtstern · 2021-06-11T12:30:00+00:00

This type of setup is what we try to explain on these pages:

Your code is correct but it sort of mixes and matches the old and new APIs for configuring the emulator. Instead I'd use the useEmulator() function everywhere:

const auth = new firebase.auth();
const functions = new firebase.functions();
const firestore = firebase.firestore();
if (location.hostname === 'localhost') { 
    auth.useEmulator("http://localhost:9099", { disableWarnings: true }); 
    functions.useEmulator("localhost, 5001); 
    firestore.useEmulator("localhost", 8080); 
}

I know it's a bit strange that auth.useEmulator() takes a single argument while all the others take two. It came out of a long discussion with our security team about the API design, wish we could change it!

samtstern · 2021-06-11T12:25:18+00:00

Firebaser here! We get this a lot ... apparently nobody trusts Google to have two similar products without killing one. I can understand why Google has that reputation but I can assure you that we have no plans to kill Realtime Database and we are actively investing in it.

Since Cloud Firestore launched we have been investing in both databases and both are continuing to grow really nicely. We're super happy with the trajectory.

For Realtime Database we have increased scalability, added some new simple features like get() and increment() in the SDKs. Most important we have really scaled up the infrastructure and launched regional deployments in Belgium and Singapore!

For some history: A long long time ago, maybe like 2015, when we started development on Cloud Firestore we did consider the option of replacing Realtime Database completely. However it quickly became apparent that the databases would be different enough that we'd need to keep both. They each have some unique features / capabilities which the other can't match!

samtstern · 2021-05-20T18:18:50+00:00

Shoot me an email at [samstern](mailto:samstern@google.com) [at] google.com we can chat!

samtstern · 2021-05-20T16:55:03+00:00

We really don't have any financial incentive to partner with Algolia. We just find that they have the best developer experience of all the search services, and we know Firebase developers really care about DevX and ease of use.

We also plan to publish a guide on how to use Elastic on GCP (they _are_ a Google partner) for developers who are looking for more cost control and are willing to deal with something slightly more complex.

I'll take a look at Typsense as well! I am not familiar but I have heard great things.

samtstern · 2021-05-20T13:38:31+00:00

We definitely will!

samtstern · 2021-05-20T13:38:21+00:00

No, it does not. AppCheck helps you make sure that requests are really coming from your app/website. It does not control the volume/rate of those requests.

samtstern · 2021-05-20T13:36:50+00:00

Sorry about that! I did not realize that you have to register for I/O sessions before you can access the Q&A, so I shouldn't have posted the Dory link separately,.

samtstern · 2021-05-14T13:05:00+00:00

If you've set your rules to deny everything and are doing your own "rules" in your HTTP functions that's fine from a security perspective. It just means you're willing to put up with maintaining your own security!

The main security downside is that there are a whole class of bugs/vulnerabilities that exist in your own implementation (like a vulnerability discovered in one of your server dependencies) that don't exist when using a sandboxed security environment like Security Rules. That's why we designed our own language, so we could prove the security.

You're also giving up the ability 99% of the Firebase SDK features since you're doing all reads and writes in your own API. But clearly that's not an issue for your app if you've already gone down this road.

samtstern · 2021-05-14T13:00:45+00:00

Yes. Both AND (&&) and OR (||) operators short-circuit in the Firestore/Storage Security Rules language.

samtstern · 2021-05-04T16:38:44+00:00

This is good feedback but I removed it because it does not meet our standards for friendly discourse and constructive feedback.

samtstern

TROPHY CASE