JEN PERSON: Hey, everyone. Welcome to "#AskFirebase,"
the show where we answer all of your Firebase questions. I'm Jen Person. And today I'm joined
by Todd Kerpelman. TODD KERPELMAN: Hi. We're here for a very special
Cloud Firestore version of "#AskFirebase." All your questions today are
all about Cloud Firestore. And hopefully we
have some answers. JEN PERSON: From
Tyler on Twitter, he asks, are auto-generated
keys in Cloud Firestore based on timestamp, like it is
in the Realtime Database? And if not, how can I
create document data ordered by document key? TODD KERPELMAN: All
right, so I hear you know the answer to that. JEN PERSON: I do know
the answer to this. I learned this actually when
we were doing our latest Zero to App talk at the
Firebase Developer Summit because we took the existing
app that we had for translation, and we changed it to
use Cloud Firestore. And that's when it occurred
to us that, no, it does not actually use auto-generated
keys using a timestamp the way that the Realtime Database does. TODD KERPELMAN: Do
you know why not? JEN PERSON: Why don't
you tell why not? TODD KERPELMAN: Fun fact,
so apparently there's one of the kind of strange but
true limits to Cloud Firestore is that there's a limit
to how many writes you can perform within a
collection on fields that have sequential or very close
to sequential value, which is kind of a weird,
obscure limit that you'll probably
never run into. But we have to worry about it
when we're generating, like, massive collections
that might have a timestamp or a timestamp-based
auto-generated document key. And it's 500 writes per
second, which, again, for a small or medium
size app is probably fine. But we want to make
sure Cloud Firestore can scale to, like, millions
upon millions of users. So we decided to go with
a more opaque document ID, not one that's time based. JEN PERSON: Yeah. Good news is, of course, you
can still query document data by create a date using a
timestamp, which is actually what we ended up
doing in our app. So we added a timestamp,
and then we ordered by that. So we'll go ahead
and link to that as well so people can see-- TODD KERPELMAN: Yeah. So you exclusively-- did
you do it on the client, or did you do it with
the cloud function? JEN PERSON: We did
it on the client actually, which, I mean,
yeah, we could have done both. TODD KERPELMAN: Yeah. Either one works. JEN PERSON: Or either. TODD KERPELMAN: Do whatever
works for your app. Just do remember there
is that, like, 500 writes per second when you have
fields with sequential values limit. But, again, for a chat
app or anything like that, you should be fine. JEN PERSON: Cool. TODD KERPELMAN: Cool. JEN PERSON: So
this next question comes from a whole lot of you. Can I do text searching or Like
queries with Cloud Firestore? TODD KERPELMAN: Have
you run into this? JEN PERSON: I've
seen this question. TODD KERPELMAN: I guess
the answer is not natively, and this is because, in
general, Cloud Firestore is built with a philosophy
that basically every query has to be fast. Like, it's basically impossible
to build a slow query in Cloud Firestore. And we sort of did that
intentionally because we don't want you in a
situation where, like, you suddenly have
to re-architect your entire database
structure because you've hit a million users and
things are getting slow. Now, this does mean
that every query you run in Cloud Firestore has
to be supported by an index. And it turns out, doing a
full text search with an index is kind of either really
tricky or impossible, depending on how
you're trying to do it, because you can't really
index for every character that's in a text string. JEN PERSON: Sure. TODD KERPELMAN:
So there are sort of some solutions that
involve third-party libraries, like Algolia or Elasticsearch. And basically what
you're going to do is you're going to
supply your text to them. And then you can run your
text on these services or run your search
on these services, and they'll give you
back a list of documents that you could then query
on Cloud Firestore directly. JEN PERSON: Would that
be a good use case maybe to use Cloud
Functions for Firebase to maybe do that
search and then-- TODD KERPELMAN: Why,
yes, that would be, yes. Actually a perfect example
for using Cloud Functions. Yeah, any time you notice
a document gets updated, you'll probably
want to do the work to make sure that
gets copied over to Algolia or Elasticsearch or
whatever third-party solution you're using. And if you check
our documentation, there's a solution section that
actually describes all this in full detail so you
don't have to figure it out all on your own. You can just copy and
paste what we did. JEN PERSON: Sweet. TODD KERPELMAN: Yeah. JEN PERSON: OK. The next question also
comes from a lot of you, which is, why did you make a new
database instead of just fixing the old Realtime Database? TODD KERPELMAN: Fix it. I didn't think the
old one was broken. It's just they just
work differently. I don't think it would have
been possible for the team to have sort of added all
the features they did, the new data structure,
the querying capabilities, the shallow queries,
and all the scalability on the existing infrastructure. Or if they had somehow managed
to cram a document database into the current
Realtime Database, it would have been, sort of, a
giant non-backwards compatible kind of mess that would have
broken all your code anyway and probably ended up
being a worse product. So I think in this case,
creating a separate database was really the smart move. And all of you who are
using the Realtime Database continue to use that. Everything just keeps
working just fine. Of course, if you can think
of a way we could have done it that would have elegantly
served the needs to new and existing
customers, let us know because maybe we'll
offer you an engineering position because that
sounds like hard work. JEN PERSON: Absolutely. TODD KERPELMAN: Yeah. JEN PERSON: Sort of
along those same lines, I've seen a lot
of people asking, what is the difference
between the two databases? And I think you sort
of anticipated already that people were going
to be asking about this. TODD KERPELMAN: I did because
there was a blog post. We'll link to it
somewhere below. Because every time you view
the blog, I get more hits. And I don't know. That makes me look cooler. JEN PERSON: We're listening. So when you come to us with
questions or suggestions, that's really how we end up
making our products better. And I think Cloud
Firestore is really a result of listening to
what people had to say about the Realtime Database. TODD KERPELMAN: Yeah, I'd agree. If you've been trying this stuff
and you have any other feedback or something, like,
you can either let us know in the
comments below. Or if you see me on the street,
just grab me and be like, hey, I got another
Cloud Firestore request. And I'll be like, OK,
but let go of me first. And then you can
tell me all about it. JEN PERSON: That's when you
know you've really made it, when you're walking
down the street and somebody asks you a
question about Firebase. TODD KERPELMAN: Yeah. I have not gotten
to that point yet. But if I do, I guess
I'll know I've made it. JEN PERSON: So you
know what to do then. When you have your
questions, make sure you post them on social
media or Stack Overflow with the hashtag #AskFirebase. And maybe you'll see
them on a future episode. TODD KERPELMAN: Are we
still doing this thing where we do, like, the hashtag. JEN PERSON: I don't know. I'm really trying to,
like, let that go. TODD KERPELMAN: All right,
you know, that's OK. JEN PERSON: Maybe-- TODD KERPELMAN: That was
kind of a season one thing. We're on to season two. JEN PERSON: Yeah, we're
on to season two now. TODD KERPELMAN: Yeah. JEN PERSON: All right,
thanks so much for watching. And I'll see you on a future
episode of "#AskFirebase." TODD KERPELMAN: It's gone. It's done.
