ABE HASKINS: So I'm going to give you names.
JEN PERSON: OK.
ABE HASKINS: And you tell me whether it's a name off
of my Markov chain machine learning
generated list of names, or if it is an actual Google product.
JEN PERSON: OK.
ABE HASKINS: KitLab Cloud.
JEN PERSON: Oh, man.
This is, like, so hard.
I'm already like, oh, no.
Fake?
ABE HASKINS: It is fake.
Good job.
App Invites.
JEN PERSON: That's-- that's a real one.
ABE HASKINS: Yeah.
That's real.
That's an easy one.
The Messaging Functions Database.
The MFD.
JEN PERSON: Yeah, that's fake.
ABE HASKINS: Dang it.
Config App Indexing.
JEN PERSON: That also is fake, is it not?
ABE HASKINS: Dang it.
JEN PERSON: I'm so good at this.
ABE HASKINS: One more.
One more.
GIT Kit.
JEN PERSON: GIT Kit?
ABE HASKINS: Yeah.
JEN PERSON: That can't be real.
ABE HASKINS: It is real!
It's real.
JEN PERSON: No way.
GIT Kit?
ABE HASKINS: Yeah.
GIT Kit was an old name for what became Firebase Authentication.
JEN PERSON: Aw, man.
To be a fly on the wall in that meeting.
Be like, yes.
GIT Kit.
ABE HASKINS: It's short for Google Identity Toolkit.
JEN PERSON: Man, you got me.
I was like, there's no way that's a real product.
Whoo, I won!
ABE HASKINS: Congratulations.
You know Firebase and Google too well.
JEN PERSON: I'm an expert.
[MUSIC PLAYING]
- It's take 1.
Mark.
JEN PERSON: Hey, all you Firebase developers,
welcome to Ask Firebase, the show where
we answer your burning Firebase questions.
I'm your host, Jen Person, Developer Advocate
on the Firebase team, and today, for my co-host,
I'm welcoming back Abe Haskins.
ABE HASKINS: Thanks for having me.
I'm so excited to be back.
JEN PERSON: Thanks for coming on.
Are you ready to answer some questions?
ABE HASKINS: I could not be more ready.
JEN PERSON: Our first question comes
from @kirinpatel, who says, is there
a way to track Firebase posting bandwidth
usage with more statistics than just total bandwidth?
ABE HASKINS: Yep.
So that's a great question.
And this is a general trend in Firebase,
which is that if you're using the Firebase Console,
you're looking at the charts we have in there,
always keep in mind that that data that you're looking at
is a simplified view designed to be approachable.
We don't want to overwhelm you with a bunch of stats
you don't care about.
And this is true in Cloud Storage.
It's true in Firestore, in Realtime Database.
All of these have some view, some amount of data available,
but it's not the full story.
And as your application grows, and as you
get into big enterprises and things like that,
you need all that granularity.
And we expose that, just not through the Firebase Console,
because, like I said, we keep it simple.
We keep it clean and approachable.
JEN PERSON: Well, where do we expose it, then?
ABE HASKINS: Well, conveniently, if you head over
to the Google Cloud Console--
JEN PERSON: Which we'll link below.
ABE HASKINS: --we have a different area
called Stackdriver.
And Stackdriver-- and Google Cloud in general,
if you're not familiar with it, it
feels like a lot of stuff going on.
There's a lot of options.
You can ignore basically all of that,
and just go look for Stackdriver Logging and Stackdriver
Monitoring.
These are two parts of Stackdriver,
which is a huge operational analysis suite.
So, basically, if you're building this huge application,
and you want to know everything that's going on in your app--
every metric and every ping and hit and miss and everything--
you could use the Stackdriver Suite to do that.
But there's a couple areas where Stackdriver looks and connects
specifically with Firebase that just
exposes a bunch of new data.
And it's not something you have to go be advanced about.
You don't have to understand really anything.
You just have to know where it is,
and you get all these great charts
and all of this great insight into your app.
So if you go into Stackdriver Monitoring,
you'll see that you can go and select Resources,
and you can say, all right, show me
all of the compute resources my project is using.
That's great if you're building on Compute Engine,
but if you're using Firebase resources,
those are in there, too.
So if you click on that, you'll find Cloud Functions,
you'll find hosting, Realtime Database usage, Cloud Firestore
usage, and you get really good granularity
on what's happening.
In Realtime Database, for example,
you get down to read operation speed, write operation speed.
You can see, why is my application slowing down?
Is it because of the REST API, or is it
because of something else?
And all of this is stuff just not exposed through Firebase,
but it's there if you need it.
And hosting is in there, too, and a bunch of other Firebase
products.
So if you're getting to that point
where you're kind of outgrowing those simpler
charts we provide, go check out Stackdriver Monitoring.
And I also mentioned stack Stackdriver Logging,
which is a more advanced logging tool.
And some of Firebase ties into that.
Stackdriver Error Reporting ties into that.
But a really good place to start is with Stackdriver Monitoring
over in the Cloud Console.
JEN PERSON: That's awesome.
I'll definitely check it out.
ABE HASKINS: Awesome.
JEN PERSON: So our next question comes to us
from @mikep, who wants to know, what are Firestore
reference fields for, and how do you use them?
ABE HASKINS: That's a great question.
If you've been using Cloud Firestore since we launched it,
you'll notice there's a couple of these types
that we say we support as values you can write to Firestore,
but we don't explain them that much.
The two of those that people talk about
are reference fields and GeoPoints.
GeoPoints are there because it's something
we're going to be using more in the future.
Reference fields are there, but they're not
used that much by developers.
They don't provide much value when you're
building your application.
What they provide value for is actually
in the Firebase Console UI.
And that sounds strange because, you know,
you're interacting with both those parts
when you're building your app, but it's actually
really important.
If you go into the Firebase Console,
and you're setting up your data structure,
you're building out your Firestore app, you might think,
all right, I'm going to have a user
and they're going to be at slash user, slash their UID,
and they might have a reference to a friend
somewhere under there.
They might have a friends collection.
If you were used to Realtime Database,
you'd think, all right, I'm just going
to put in a string that is that user's
unique ID for the friend.
And then, when I'm on the client, I'll go,
I'll rebuild that path and say, all right, slash users,
slash their friend ID, and I'll pull out their information.
Now, reference fields are like that.
They give you a reference to another point in Firestore.
But the reason it's better is not
because it allows you to do any fancy loading.
So, for example, if you load that collection,
you get back that it's a reference field.
You don't get back the actual data of the user.
So it's not like a link to there,
where it's going to magically simplify your queries,
or anything like that.
But, if you have it set as a reference type,
and you go in to the Console, and you
look at that field, when you click on it, instead of just
modifying the string, you'll actually
get a rich editor that allows you
to go select another document.
So now, instead of typing in a string
that you'll pull in in your client,
that's going to be easy to make a mistake about--
it's something that you might reference
a document that doesn't exist.
When you're editing it in the Console,
we can build up that nice UI, because we know this is just
a pointer to another document.
And that's the real value of these,
is it makes it less likely that you're
going to have some mistake when you're
editing things in the Console.
And, in the future, we might be able to do some cool things--
lazy loading, things like that.
But, right now, that's the real value,
is it is just a little less error
prone than just throwing strings to reference other docs.
JEN PERSON: Nice.
That's really good to know.
I always wondered about that reference field.
Now I can see that it prevents you
from messing up and making that a reference to something
that doesn't exist.
ABE HASKINS: Mhm.
Exactly.
And you'll see that, as we move forward,
we're planning that with other types, where
we can make that UI better and make it stronger,
so it's just less likely that you're
going to do those mistakes you could
do in RTDB, where you click the wrong thing
and delete everything, or click the wrong thing
and change its type accidentally.
We're trying to really make that UI
more powerful than the Realtime Database one ever could be.
JEN PERSON: Yeah.
I already really enjoy that you can type in the path
and find a specific location.
Because that was always a pain before,
having to scroll through the database and be like,
what is that particular field that I was looking for?
And this allows you to really pinpoint much quicker.
ABE HASKINS: Yeah.
And we realized-- we saw people just
editing the URL in the navigation bar to do that,
and then we were like, maybe we should make this a feature
because they just ended up-- yeah.
JEN PERSON: Wow.
That's a good idea.
Now I feel like I should have done that.
ABE HASKINS: Well, now you don't have to
if you build on Firestore.
JEN PERSON: Nice.
Well, thanks so much for coming on the show tonight.
ABE HASKINS: Yeah.
Thanks for having me.
JEN PERSON: It's been great having you,
and I learned so much.
ABE HASKINS: Yeah.
Thank you.
It's lovely.
It's always great to come on.
Hopefully I'll see you again soon.
JEN PERSON: Yeah.
And thank all of you for sending us your questions.
Please keep them coming our way.
It's the only way we can keep making the show so great.
Thanks so much for watching, and I'll
see you on a future episode.
[MUSIC PLAYING]
Do you want to just like have a conversation,
or do you want to dive in and answer some questions?
ABE HASKINS: We can dive in.
Hi, I'm Jen Person.
This is Abe from the Firebase team.