JEN PERSON: Time is nonexistent when you're in here.
It's sunny all day and all night.
[MUSIC PLAYING]
FRANK VAN PUFFELEN: That's actually true.
Look into the light, Jen.
Look into the light.
JEN PERSON: It's going to hurt in a minute.
I should probably stop looking into the light.
FRANK VAN PUFFELEN: Actually, that's also true.
JEN PERSON: Hey, all you Firebase developers.
Welcome to another episode of AskFirebase, the show
where we answer your burning Firebase questions.
I am Jen Person.
And today, my co-host needs no introduction.
FRANK VAN PUFFELEN: What?
You said needs no introduction, right?
JEN PERSON: Yeah.
FRANK VAN PUFFELEN: OK.
JEN PERSON: So this is Frank van Puffelen.
And for those of you who don't know,
he is definitely our most prolific Stack Overflow
question answerer--
FRANK VAN PUFFELEN: I think so, yeah.
JEN PERSON: --in addition to being a developer of programs
engineer on Firebase, yeah.
GP.
FRANK VAN PUFFELEN: I like saying Firebase engineer.
It sounds a bit simpler.
JEN PERSON: Firebase engineer.
FRANK VAN PUFFELEN: Yep.
JEN PERSON: OK.
Yeah.
It is a very long name.
Sometimes I feel like they just, like, pull them out of a hat,
you know?
FRANK VAN PUFFELEN: This one pretty much did.
Yeah.
JEN PERSON: Yeah, thanks so much for coming back on the show.
It's always a real pleasure to have you here.
FRANK VAN PUFFELEN: Same here--
I mean, I get to talk out loud when
answering questions, instead of typing them on a keyboard.
JEN PERSON: You tell me you don't, like, speak them
out loud while you're typing?
FRANK VAN PUFFELEN: It would be awkward when
I'm answering them on a bus.
So--
JEN PERSON: We don't sit next to that guy anymore.
FRANK VAN PUFFELEN: Oh, that's always the case.
JEN PERSON: Muttering to himself.
OK.
So let's get down to it, shall we?
FRANK VAN PUFFELEN: Yes.
JEN PERSON: So our next question comes
from Brian Hong on Twitter.
He says is a uid secret data?
I'd assume it needs to be attached to other data sources,
and doing so doesn't violate best practices?
So is it safe to share this?
FRANK VAN PUFFELEN: It's a really good question, Brian.
It actually is not sensitive data at all.
So a Firebase authentication uid, right,
identifies a specific user within Firebase authentication.
And it doesn't do anything more than that.
And you have many, many places where you have an ID already,
right?
For example, on Stack Overflow, my ID is 209103.
Yes.
I know my Stack Overflow ID.
Right?
But knowing that doesn't allow you to do anything, right?
You can't now go to Stack Overflow and sign in as me.
Because you don't know my sign in credentials.
So there's a very clear distinction between sign
in credentials and the ID.
And the ID you can totally share.
That's why I just told you that my Stack Overflow ID is 209103.
Right?
So now you can definitely simply store the uid
with any other records that you want to relate to that user.
In fact, that's what we recommend you do.
JEN PERSON: I'm really bummed that I just don't know mine
off the top of my head, too.
So I could be, like, well, actually mine is this.
Are they, like, in number order, so you're like the 209,000--
what did you say 103rd--
FRANK VAN PUFFELEN: Mhm.
JEN PERSON: --uh, wow.
FRANK VAN PUFFELEN: Yeah.
There were still a few people before me on Stack Overflow.
JEN PERSON: Yeah.
But certainly-- I mean, you're right up there
with the most prolific responders.
FRANK VAN PUFFELEN: Yeah, it's a bit
of an interesting competition recently for Firebase.
But I've been doing this for a while.
So definitely the number one of Firebase for all time.
It's lovely helping people.
JEN PERSON: Yeah, definitely.
I always want to, too.
But you have to be watching it.
I have to be sitting there waiting
for it to say one new question.
And then, like, sometimes I'll submit my answer before it's
complete, because I know that you're
going to get there before I do.
So definitely a competition--
I know I'm not in the running.
But I'm trying to do my part.
FRANK VAN PUFFELEN: Maybe I should host some AskFirebase.
And then you can answer questions in the meantime.
JEN PERSON: OK.
Yeah.
[LAUGHTER]
I'll be over here answering questions.
FRANK VAN PUFFELEN: It is, at times, a competition.
I do notice that.
And Doug Stephens is one of our other very prolific answerers
from Google.
But we also have community members
who answer a lot of questions.
JEN PERSON: Yes, we do.
FRANK VAN PUFFELEN: And we love that.
JEN PERSON: Yeah.
I greatly appreciate that.
Because we're only like a handful of people.
We definitely depend on our community members to help out.
FRANK VAN PUFFELEN: Yeah.
Do we have any more questions, you think?
JEN PERSON: I might have a couple.
FRANK VAN PUFFELEN: OK.
Let's go for it.
JEN PERSON: OK.
Our next question also comes from Twitter.
And Sylvia wants to know--
they saw a video, a great video about Firestore pricing.
Could I use a hybrid approach of using the real time database
and Firestore for different kinds of data?
Or is there any reason not to do that?
FRANK VAN PUFFELEN: I love the new 280 character
limit on Twitter, by the way.
We get much, much more complete questions.
JEN PERSON: So yeah, it is like almost impossible to ask a tech
question in 140 characters.
FRANK VAN PUFFELEN: And it's definitely
possible to combine Firestore and real time
database in a project, right?
There are still some use cases that Firestore doesn't offer.
For example, it doesn't have a present system.
Because actually, the protocol that we used
doesn't support presents.
So that's a good reason to still use [INAUDIBLE] database
in your project.
And you can definitely just combine them, right?
You just import both of the STKs,
and then you can read from the one and from the other.
They don't conflict with each other in any way.
So yes, it should totally be possible.
And it doesn't really matter whether you do that
for pricing reasons, or for reasons with the feature,
right?
Both are complete developed.
And the real time database is there for you to use.
JEN PERSON: Yeah.
And if you have to share data between them,
you have the server side SDKs, the admin SDKs,
which can allow you to access Firebase products
from a server.
And you could trigger them using cloud function.
So when you make a change here, you
can copy it over into the other database, so on and so forth.
FRANK VAN PUFFELEN: It's actually a really good one.
We see that happening occasionally now, right,
where people are not sure yet which
database they want to use.
So they start with one and then write a cloud function
that copies the data from one to the other, which is actually
a totally valid approach.
And it's a great way to test out both the databases that we have
and see which one works best for you.
JEN PERSON: Cool.
Thank you for your question.
That was great.
You ready for another one?
FRANK VAN PUFFELEN: Let's do it.
JEN PERSON: Our next question comes from Igniter.
Igniter says I want to get the number of unread messages
for a given user by one query.
How would you implement such a task?
FRANK VAN PUFFELEN: Ooh.
Let me think.
That one is always a bit tricky.
Actually, there is the naive approach
that you think you always need.
And then there's the one that I usually do.
So the naive approach is that you
start tracking what messages each user has read.
By that, it means that you need to have a message ID, and then
a user ID, and whether they've read the message.
And that's definitely possible, but it's
going to lead to an explosion of data, right?
Because as you get more users, you get more messages,
and you also need to track of more messages,
whether the user has read them.
So while it's technically possible,
it's not the approach I would normally recommend.
A much simpler approach is actually
to track the last message that a user has read,
so if you would see all messages as a long list of messages,
chronological.
Then all you actually need to know
is normally you show messages in an app from oldest to newest.
So what you need to know is what was the newest
message that they saw, right?
And this one you can store either in the database
or in the local storage of your app.
And then when the app restarts, you just
read that single value.
Let's say that it's a timestamp.
And let's say that you loaded it yesterday for the last time.
Then you do a query, give me all messages
that have a timestamp newer than yesterday.
And with that, you can simply get all the new messages
and then track which ones they've actually
seen by, for example, tracking the scroll position.
A much simpler approach, because you only need to store one
value for each user.
And it works pretty well, because a lot of chat apps
actually use this.
JEN PERSON: Cool.
Good call out.
FRANK VAN PUFFELEN: OK.
Jen, we have a question for you, actually, I see.
JEN PERSON: Boy.
FRANK VAN PUFFELEN: Yeah.
It's from Twitter.
And it says Cloud Firestore triggers support
onCreate, onUpdate, onWrite, and onDelete
as their trigger, a reason.
Could you add an onSnapshot trigger
so that it fires whenever a user subscribes or unsubscribes
from the data in either a collection or a document?
It would be really helpful, right,
to monitor user activity.
JEN PERSON: Yeah.
I really appreciate this suggestion.
And whenever you have feature requests,
if it's something that you really think pertains
to your particular app, please be sure to file those.
And we will link the feature request below.
In response to this specific example,
keep in mind that you don't necessarily
want to track specific users and what
they're doing in your app for privacy reasons.
But something you could sort of do
if you want to monitor overall how many people are doing
this activity or that activity, you
could use a Google Analytics trigger.
So when you have some sort of conversion event that runs,
then you could trigger a Cloud Function off
of that, which could allow you to keep
track of a certain event and maybe do something in response
to it.
When someone subscribes to a specific,
or reaches out to a specific collection,
you could also fire a Google Analytics
event at the same time.
So you could use that as a trigger.
If it's something where you want to respond to the client,
and maybe you're not collecting that sensitive information that
could identify specific users, you
could have them write to a specific place
in the database at the same time,
or send out an on call function.
There are definitely other ways around it.
But overall, I'd say probably your best bet
is a Google Analytics trigger.
FRANK VAN PUFFELEN: That's a good one, indeed.
Yeah, for sure.
JEN PERSON: Puff, thank you so much for coming on the show.
I really appreciate having you here.
And do keep those questions coming because we
need those to make the show.
We really can't do it without you.
So when you're building some sort of Firebase project
and you have a question, you know, if it's a long one
and it has code, be sure to put it on Stack Overflow.
But you can also put a link to Stack Overflow on social media
with the hashtag AskFirebase, and we do take a look at those,
as well.
And if you like the content you see
here, be sure to subscribe to the Firebase YouTube channel
so you can see all of our new shows right when they come out.
Thanks so much for watching.
And we'll see you on a future episode.
Bye!
FRANK VAN PUFFELEN: Wait, did somebody just
say that I'm not agreeable?
Oh, it was me.
JEN PERSON: I disagree.
FRANK VAN PUFFELEN: It's not a problem.
[LAUGHS]