LAURENCE MORONEY: Is this the first question?
JEN PERSON: Yeah.
LAURENCE MORONEY: I'm not answering that one.
JEN PERSON: Hey, everybody.
How's it going?
Welcome to another episode of Ask Firebase.
I'm your host, Jen Person.
And today, my co-host is Laurence Moroney
and we're going to answer your burning Firebase questions.
Shall we just dive right in?
LAURENCE MORONEY: Love the pun.
Burning Firebase questions.
JEN PERSON: Yeah, get it?
I love a good pun.
LAURENCE MORONEY: I'd never thought of that one myself.
JEN PERSON: Welcome to the show.
Thanks for coming on and answering some questions
with me today.
LAURENCE MORONEY: I'll do what I can.
JEN PERSON: Let's see what our developers are asking about.
Let's see here.
Scroll, scroll.
Let's start with this.
Vaibhav Fuke on YouTube asks, "If I
am a beginner to Firebase--
let's assume-- should I start with Firestore,
or the realtime database?"
LAURENCE MORONEY: Oh, that's a really good question.
JEN PERSON: I love that question.
LAURENCE MORONEY: The easy answer to that
question is, it depends.
Because it really depends on what you want to do.
And the piece of advice that I usually give
is that if you're used to existing
databases, like relational databases, those kind of things
that have tables and indexes, and structures
and that kind of thing, it's probably less of a bump for you
to go straight to Firestore.
JEN PERSON: I can agree with that.
LAURENCE MORONEY: Because it has that kind
of document collection thing.
If you don't have existing database knowledge,
or if you're used to working with data in JSON documents,
as a lot of web developers, for them,
realtime DB is just the perfect fit.
JEN PERSON: Absolutely.
Having had past experience with JSON documents,
it felt just really comfortable first
learning realtime database.
And it was actually kind of fun to learn
all about denormalization.
LAURENCE MORONEY: Either of them you can start with, right?
They're both very, very easy.
They both work effectively in real time.
For me, I come from a relational database background,
so it was kind of square peg, round hole for me
to start using realtime DB, but then I
got to really enjoy that.
But now that I'm going back to the Firestore-type stuff,
I'm actually having a lot of fun with it,
querying and documents and all that kind of stuff.
It's pretty cool.
JEN PERSON: Yeah.
And we have code labs for both of them.
So why not both?
LAURENCE MORONEY: Yeah, why not both?
And they're both code labs you can do in half a day, right?
So spend half a day doing both of them,
and then choose what suits you.
JEN PERSON: Sounds good.
Let's see what we got next.
Keep going.
I answered that one.
That was a weird one.
We're going to do this one.
So our next question comes to us from Twitter.
And Andrew Walpole wants to know,
"Any way to link a single user to auth into multiple Firebase
products?"
LAURENCE MORONEY: So the same user across multiple Firebase
projects?
Right now, no.
But there is probably one thing you can do.
I'm guessing what your scenario is
and that it's you want to be able to sign
the user into multiple applications,
and these multiple applications, each one
is built with a particular Firebase project.
So if you sign your user up and they're using the Google ID
and you're using smart lock for passwords,
once they've signed in the first time,
then subsequent sign-ins are invisible.
So you can actually build it so they sign in using their Gmail
ID, so their Google ID, and then once you've--
there's a simple API for you to store that in smart lock
for passwords.
And then subsequent times they open, they sign in right away.
So you can kind of get the same effect.
If you've got 10 apps, you sign into one, you're in.
You sign into the next one, you're in.
And then subsequent times, you open them,
you're just directly in.
So while it's not the single user being synchronized across
multiple Firebase projects-- we don't support that yet--
at least you can have a good user experience for a user
being able to sign into multiple applications that you've built.
JEN PERSON: But I really like getting
these kind of questions, too, because it
shows us a lot about things developers want
to do with Firebase and gives us a good direction
for the project.
So these are great, great questions that people have.
And that's how we drive the direction of our product.
LAURENCE MORONEY: Absolutely.
We can learn as much from you as, hopefully, you
can learn from us.
JEN PERSON: Great.
The next question comes actually from [INAUDIBLE],,
who I was sitting next to during the Firebase dev summit.
LAURENCE MORONEY: Oh, you were?
JEN PERSON: Yeah.
So hi.
LAURENCE MORONEY: Hey, [INAUDIBLE]..
JEN PERSON: Where can I find out more info on Firebase and GDPR?
This question comes up a lot from our developers,
especially anyone who wants to have their app in Europe.
LAURENCE MORONEY: Yeah, it's important to have
that kind of protection.
So I know Francis Ma spoke a little bit about it
during the keynote at the Firebase summit.
And I believe there's a website, and I
think we have a link in the comments below.
JEN PERSON: Oh, yeah.
Look at that.
Now, magically, we have a link.
So yes, where can you find out more?
In the links below.
So the next question comes to us from Stack Overflow,
and it's a pretty long one, so I'll just summarize.
But essentially, we have a developer
who wants users of the app to be able to submit quotes
anonymously.
But they don't want just anybody to be able to access that data.
They just want users of the app.
So they want to know how can they
protect that without forcing people to sign in.
LAURENCE MORONEY: So we do have the concept of anonymous users.
JEN PERSON: Yes.
That's what I was thinking.
Exactly.
LAURENCE MORONEY: I'm wondering if we could do something
like that.
So the idea behind an anonymous user
is that the user entity is still treated
as they are a user within the database,
so security rules can be applied to them, that type of thing.
So they don't need to sign in with a username and password
or anything like that, but security rules
can still be applied to the concept of an anonymous user.
So I think that kind of thing might be able to be used.
JEN PERSON: Yeah, I think that makes sense
to me, because not every app necessarily
needs to hold on to so much of the user's information.
But it's still a good idea to be able to know
who's using your app.
So that's where the idea of anonymous auth
is really useful, and I think this would be a great way
to make sure that not anybody is using your app.
LAURENCE MORONEY: Yeah, and another great use
that we have for anonymous auth is that, a lot of times,
you want to give data to users of your application
who are signed in, but you don't want them to sign up
before they can have an experience of using
your application, because if you ask people to sign up,
they may go away.
So the idea is that you can have one set of data
from your application that's available to anonymous users
and then another set of data that's
available to signed-in users.
So now, the anonymous users will get that experience, both
when they're signed out and then after-- sorry, before they
sign up and then after they sign up when they get both sets,
when they're actually signed in.
JEN PERSON: Right.
Yeah, so you can actually convert that, too, right?
So once they sign in as a--
let's say with email and password,
you can hold onto that data.
LAURENCE MORONEY: Exactly.
Exactly.
So it's kind of for trial data, that type of stuff.
Because I mean, how many times have you gotten an app
and it asks you to give all your personal information
before you can even use the app?
JEN PERSON: And then I just delete it.
LAURENCE MORONEY: Exactly.
So that's one of the cool things about this, is maybe--
I don't know if it's a sports application
or something like that-- and you want to see scores,
you don't need to sign up to be able to see the scores.
But if you want to go into some details and see a box score
or see details of the players or something like that,
then you have to sign up.
At least you've had an experience
before you sign up for it.
And that's what anonymous authentication gives you.
It's pretty cool.
JEN PERSON: Absolutely.
I use it a lot when I'm testing things or trying to answer
questions from Stack Overflow.
Again, if I have my Firebase project
that I'm just testing things out on,
it's so nice to just be able to do anonymous auth,
because I don't have to set up a whole authentication
scheme and all these views that I'm not necessarily
going to use.
I can just boom, be authenticated,
and still know that the data isn't just publicly available.
So I have a question about a new product Firebase predictions.
And you're my go-to guy for that.
So I would like to know, is it possible to set up
a prediction for any kind of analytics event?
LAURENCE MORONEY: Oh, I see.
That's a really good question, because it
can be a little bit confusing.
The type of predictions you would set up
would be for conversion events rather than
any analytics event.
And a conversion event is something
that you can define manually.
So technically, it can be any analytics event.
But it will only be the ones that you
define as a conversion event.
And the reason for that is pretty obvious
when you think about it in that you
want to be able to predict the major things in an application
life cycle.
So for example, if you're building a game and the game
has n levels, but you realize that once the user has played
three levels, they're going to be hooked
and they're going to play the game for the rest of time,
then it's a case of, you would say,
once they've passed level three, I'm
going to set that as a conversion event
and then I want to predict which users
are going to hit that, or many ways
more importantly, which users are not going to hit that.
And the ones that aren't going to hit that, then I
can provide some kind of encouragement
for them to keep playing the game until they hit that.
And then once they've hit that, I
know they're going to continue playing the game forever.
JEN PERSON: Got it.
So you'd want to set up some conversion events.
Those would be the major happenings in your app
that keep a user.
LAURENCE MORONEY: Yeah, exactly.
Keeps them engaged.
And it's just a little switch that you
hit on the Firebase console for that analytic,
and it's as easy as that.
JEN PERSON: I mean, that sounds great.
I am super excited about predictions.
I mean, that makes so much of the developer's work so much
easier.
You don't have to guess.
What a time to be alive.
LAURENCE MORONEY: Oh, yeah, and we're only getting started.
JEN PERSON: Well, Laurence, thank
you so much for coming on and answering
some of these Firebase questions with me.
LAURENCE MORONEY: Always a pleasure.
Thank you.
And thanks for all the questions.
JEN PERSON: If you have Firebase question,
make sure that you post it on social media or Stack Overflow
with the hashtag #AskFirebase, and maybe you'll
see it on a future episode.
LAURENCE MORONEY: And if it's a really difficult one,
don't tag me in it, please.
JEN PERSON: You were tagged in one of those questions.
Yeah.
All right, thanks so much for watching
and I'll see you next time.
LAURENCE MORONEY: See you.
I like it.
Snazzy.
JEN PERSON: Isn't it snazzy?
LAURENCE MORONEY: It is.
JEN PERSON: It's classy.
LAURENCE MORONEY: It's got Firebase [INAUDIBLE]..