TODD KERPELMAN: OK, skip everything that we just said.
JEN PERSON: Just pretend that didn't happen.
TODD KERPELMAN: We don't think we actually
knew what we were saying.
CREW: This is take one-- mark.
JEN PERSON: Hey, Firebase developers.
How's it going?
Welcome to another episode of "#AskFirebase."
I'm your host, Jen Person, and my co-host for today
is Todd Kerpelman.
TODD KERPELMAN: Hey, Jen.
JEN PERSON: Hey, welcome to the show.
TODD KERPELMAN: Thanks, it's been a while.
JEN PERSON: It's been a minute, yeah.
TODD KERPELMAN: I like what you've done with the place.
I think those plants are new since I was here last.
JEN PERSON: Yeah, you know, I've been watering them.
You can see that they're growing.
TODD KERPELMAN: They look healthy.
I was thinking they totally look like they're
doing great inside of this studio
without any actual natural sunlight.
Fantastic!
JEN PERSON: All right, you ready to answer some questions?
TODD KERPELMAN: Are they about plants?
JEN PERSON: Not this time.
TODD KERPELMAN: Oh.
JEN PERSON: I'll grab some for next time.
TODD KERPELMAN: Well, you can answer some database
related ones or something.
We might have one of those.
JEN PERSON: I think I have a couple.
TODD KERPELMAN: Let's find out.
JEN PERSON: Here I have a question
from David Weinberg who wants to know, "I am starting
a new project now, and it'll be a couple of months
before it's ready for production.
Should I stick with Firebase Realtime Database
or go with Cloud Firestore even though it's still in beta?"
TODD KERPELMAN: Good question.
Thanks for asking it.
I would say that if you're kind of scared or staying away
from Cloud Firestore because of that beta tag,
don't let that be the thing that turns you off.
There are actual real production apps out there
in the real world right now that are using Cloud Firestore.
It should be fine for your app's needs.
That being said, you really should kind of
evaluate these two databases on their own merits
and decide which one's best for you.
I generally recommend Cloud Firestore
for most general purpose apps.
On the other hand, if you have something, maybe
like a real-time drawing app or something that
might have a lot of very small but very quick updates,
the real-time database still might work better for you
from sort of a technical and pricing standpoint,
but I'd kind of lean toward Cloud Firestore,
and don't let the beta thing scare you off too much.
JEN PERSON: Yeah, great question.
TODD KERPELMAN: It was.
JEN PERSON: And great answer.
TODD KERPELMAN: I might have seen that one in advance.
I might have answered that one before.
JEN PERSON: It's definitely possible.
Actually, it was a great question.
He put it as a Twitter survey, which
I thought was really a good way to evaluate it.
TODD KERPELMAN: What did the twitterers say?
JEN PERSON: They said Cloud Firestore also.
TODD KERPELMAN: All right.
JEN PERSON: So I think that's the right choice.
Next question comes from Alvin Conda
who wants to know, "what is the best way to share
a collection of docs with some users
so all the users can write and read to that collection?"
TODD KERPELMAN: All right, so basically, I
think what you're looking for is essentially creating an access
control list.
Generally, the most common way you want to do this
is store your users either as an array or a map,
where you might have your user IDs in an array or a map
where the keys are the user ID, and their value
is the role that they have within your application.
And put that either in the same document,
where you're sort of trying to control access,
or a sibling document, or a child in a sub-collection
somewhere.
And then basically use security rules
to say, hey, you know what?
Any user can access this document
if their user ID is listed in this array or this map
in this other document.
I know that sounds a little confusing,
but we have lots of videos on the topic.
I know Mike McDonald just released a Firebase Pro Series
video all about security rules where
I think he used this very same example,
so you can check that out.
You can also check out my own "Get to Know Cloud Firestore"
videos.
Numbers five and six, if that's out, both sort of
talk about this topic, so check those out as well.
JEN PERSON: Also, I might add, if you just
have a couple of different roles,
and let's say you have some sort of moderator
and a regular user, that could be a good use case for using
custom claims, which you can set using Firebase authentication.
So we have a code lab that shows how to do that.
And what custom claims allow you to do
is put a little bit of details in the user about what
their permissions are.
So this won't be inside the database,
but you can access those claims from Cloud Firestore rules,
or Cloud Storage rules, or real-time database rules
so you can check for the existence
of that claim on a user.
TODD KERPELMAN: Yes.
Those are good for if you want to have database-wide level
permissions, like this admin can access anything in my database.
I think custom claims work really well there.
JEN PERSON: Yeah.
Yeah.
If you're looking at some use case
where you might have a whole bunch of different rooms
with various combinations, what you're describing
is probably a better use case for that.
TODD KERPELMAN: All right, but good suggestion.
JEN PERSON: Next question is from--
every time.
What do you think?
"Saro-vayo?"
TODD KERPELMAN: "Sera-vow."
JEN PERSON: "Sera-vow."
Yeah, we're going to go with Seravow.
I like that.
TODD KERPELMAN: It sounds coolest.
JEN PERSON: "How can I clear local persistence,"
meaning their cache, "I have an app
that enables multiple users.
When I log in with the other, the first one's data
is still there."
TODD KERPELMAN: OK, so this is a very common feature request
that we have.
The team knows that this is something the community has
been asking for, so they're certainly
looking into just being able to have you
as a developer say, hey, clear out all my local cache.
If that is not available, the best solution right
now is basically you can set persistence
to false within your database settings.
And then actually, what will happen
is essentially as soon as one user logs out,
if you detach your listeners and then reattach them again
when they log back in, say, as a different user, that
will essentially clear out all your cache data.
So for now, that's probably the best way,
is just kind of set persistence to false
if you have an app that you think
is going to be used a lot on a shared computer or device.
JEN PERSON: Cool.
Good to know.
See?
I didn't know that.
That's why I'm so glad you're here.
TODD KERPELMAN: All right.
JEN PERSON: Our next question--
TODD KERPELMAN: Wait, this one looks like it's for you.
JEN PERSON: Oh, yeah, but I'm passing it off to you.
TODD KERPELMAN: Wait a minute.
JEN PERSON: Yeah, yeah.
So this next question comes from Henry,
who asks us a lot of great questions.
When it comes to, let's say, having a display
name and an avatar for a user, does it
make sense to just have that UID for that user in each location
in the database, or does it make sense
to replicate the display name and avatar
in every single location?
So I mean, if you're having a chat conversation,
should you be repeating that every time
or just have them look it up in the database each time?
TODD KERPELMAN: OK, so this is essentially
kind of going into the question of denormalized data in NoSQL
databases.
The answer is, it depends.
Generally speaking, I would say, take
a look at how often you're going to want to read this data,
and how often do you think it's going to change?
So for instance, if we've got a chat app,
and you've got, say, your user, and they
have their name, and profile picture,
and a few other things, and you're
copying that data into, say, every document for every chat
that they're in, you're going to have
a lot of denormalized data, meaning
that copy is going to exist in a lot of different places.
Now, in general, from a NoSQL world, that's OK.
The idea is that your app is probably
going to be reading in these documents a whole lot
more often than this user is going
to be changing their name.
And so the whole NoSQL philosophy
is, let's take this very common case of reading in your data
and make that super easy, versus sort of the one time
a year when your user decides, hey, I'm
going to change my name from Charles to Chuck, or whatever,
and that part ends up being a little more of a pain to do.
So in general, I would say go ahead
and copy the data you think you're going to be reading
in every time everywhere.
And then kind of deal with probably using a Cloud
Function, as you pointed out, changing the denormalized data
in a few batch calls when that user ever does
decide to change their name.
JEN PERSON: Yeah.
I love-- thinking about NoSQL is always a challenge,
especially if you're coming from a SQL background.
So one way that I've always tried to imagine it is,
taking a look at any view in my app,
what is it that I'm going to want
to see on a regular basis from that screen?
And how can I get it in as few queries
to the database as possible?
TODD KERPELMAN: Yes, that's a good way of looking at it.
JEN PERSON: Right.
So if you're getting some sort of thing
where you're doing a query, and then nesting another one,
and then nesting another one, it might be a good opportunity
to look at how you're structuring your data
and changing that structure.
TODD KERPELMAN: Yes.
Hey, Jen, I got a question for you.
This one comes from our YouTube channel who's wondering, "Hey,
can my browser receive Firebase Cloud Messaging data
as a data-only notification the way I can on mobile devices?"
JEN PERSON: That really depends on the limitations of Web Push.
So I really love this question.
At any given time, the way that notifications
work on web clients is FCM, Firebase Cloud Messaging,
wraps it up and then passes it off to the Web Push Protocol.
So whatever is available is really dependent on what
that enables you to do.
So whatever key value pairs are currently
available on Web Push, those are the ones
that you will be able to use.
That being said, if you are frequently
sending messages that just have data in them, that
might be a better opportunity to send something or store it
in a database.
There might be some opportunities for listeners.
It really depends on your use case.
So the short answer is--
sort of.
It really depends on whatever is currently
available in Web Push, so I would check out the link
below to those standards so you can send those.
TODD KERPELMAN: I'm glad you're here
to answer that question because I haven't done any web
development since jQuery was a hot new thing.
JEN PERSON: Ooh.
TODD KERPELMAN: Yeah, I know.
It's been a while, so all this push stuff,
it's all foreign to me.
JEN PERSON: Those were some really great questions.
TODD KERPELMAN: They were some great questions.
And one bad question-- you know who you were.
JEN PERSON: Thank all of you for asking questions,
and thank you, Todd, for coming on and helping me answer these.
TODD KERPELMAN: Sure thing.
I hope they were right.
JEN PERSON: And in order to keep making the show,
we need to keep getting your questions.
So be sure that when you're coming across something
that you know might be a common problem that a lot of people
want to know the answer to, be sure to hit on social media
with the hashtag #AskFirebase, and who knows,
maybe you'll see it on a future episode.
TODD KERPELMAN: And then you'll be famous.
JEN PERSON: Wow.
And if you liked what you see here,
be sure to subscribe to the Firebase channel for more
awesome content, and we'll see you on a feature episode.
TODD KERPELMAN: Bye, internet.
JEN PERSON: Bye.
TODD KERPELMAN: Are you guys talking about us?
They're talking about us.
CREW: No, we're talking about badges right now.
TODD KERPELMAN: Oh.
JEN PERSON: What?
Pay attention.
CREW: Yeah, sorry.