[MUSIC PLAYING]
JEN PERSON: Hey all you Firebase developers,
welcome to another episode of AskFirebase,
the show where we answer your burning Firebase questions.
So today, I am joined by Abe Haskins.
And Abe is a developer programs engineer.
What does that mean?
ABE HASKINS: Basically, it means that I do programming related
to helping people use Firebase.
JEN PERSON: Well, perfect.
I got some questions together that we
can take a look at and maybe answer together,
if you want to do that.
ABE HASKINS: Absolutely.
JEN PERSON: So our first question
comes to us from Twitter from [? avanderbergh. ?]
And the question is, "If I use the get function in a Cloud
Firestore security rule to retrieve a document
to validate against, does this count towards my Firestore Read
Operations or any other quotas?"
ABE HASKINS: Yep.
So, first off, anything related to pricing, always
check out our pricing page.
We have a very detailed description
of how every possible operation impacts
what you will be paying.
So this does change.
You know, what I'm saying here applies today.
But always check that for the source of truth or anything
related to pricing.
Right now, the way it works is that if you
read from Firestore from anywhere,
it counts as a Read Operation.
So that get is a read operation.
What it doesn't count as, though,
is any network bandwidth.
It's not outgoing, it's not incoming.
It's happening within our infrastructure.
So it is a Read Operation, but it's not outgoing request
or incoming request.
So it's a little cheaper, but it is still a Read Operation
against Firestore.
JEN PERSON: OK, well that's good to know,
because I saw that question, and I was, like, yeah,
that's actually very valid.
And we'll also link to anything pricing related.
We'll link to that pricing part, because probably users
have a lot of different questions related to pricing.
ABE HASKINS: Yeah.
And we put a ton of effort into describing the Firestore
pricing in the most reasonable way.
So that document is really good at answering all sorts
of pricing related questions.
JEN PERSON: Sweet.
Thank you.
Let's hit another one, shall we?
ABE HASKINS: Mm-hmm.
JEN PERSON: OK.
You're just laughing at how I have to keep reading the names.
ABE HASKINS: Yeah, the names are good.
JEN PERSON: Oh, how's she going to do this one now?
[? Oche2 ?] asks, "Is there anything
special to watch out for when building PWAs with Firebase?"
So maybe we should just start with what's a PWA?
ABE HASKINS: So, a PWA isn't actually anything.
It's kind of a group of web standards
that if you were building things using these web standards,
you're building a PWA.
So people use this to mean a few things
in general, which is that a PWA is a web app that's
bundled in a specific way that can be used offline, that
can be very fast, preferably faster than a normal web
app would be, and it can be installed to the home
screen of your device.
So there's a bunch of--
JEN PERSON: So a progressive web app
is supposed to behave as much as possible like a native app.
ABE HASKINS: Yes, exactly.
But instead of being distributed through the App
Store or the Play Store, you go to the website
and it says, hey, would you like to add this
to your home screen?
And when you do it does some magic,
and it bundles up that page and shows it like a native app.
JEN PERSON: Now, why might someone
want to do that instead of a regular web page or--
ABE HASKINS: Well, the big advantage
is that it kind of gives you a presence on the user's device.
So you can have what feels like a normal app
without them having to go hunt it out.
Because it's very easy to get someone to your website,
and then you can easily pop up the dialog
that asks them if they want to add it to the home screen.
So you're not going through the whole burden
of saying go to the Play Store, install this.
You can just say, oh, now this web page you're already using,
you are already familiar with, is now there.
And if they say no, that's fine.
They can keep using it as a normal web page,
and it's not going to hurt the experience at all.
JEN PERSON: OK.
So that being said, if I want to use Firebase
to make a progressive web app, what
do I need to watch out for?
ABE HASKINS: Yeah.
So there's one big thing that catches everybody
in about 10 different ways.
And that is that a PWA is really based on this idea of a service
worker.
And a service worker is a client-side proxy
that all of your web requests go through.
So when you request that index@html page,
it doesn't go straight to the server.
It goes to a service worker, and your service worker
looks in a cache, and it says, all right,
do I have a version of this?
And in that service worker, you write just normal JavaScript,
but it can influence what's returned from the cache.
And the reason you do this is because to get really good
offline you need a ton of control over what gets cached.
You want your images to be cached but not your dynamic API
calls and things like that.
So if you're using a service worker
and you're building it from scratch,
by default when you go and write, like,
the simplest service worker, it caches everything.
And you're probably just going to throw it in a cache
and retrieve it later.
And if you do that, you are going to end up
with a bunch of crazy behavior.
And this is true not only if you're writing one
from scratch, but if you're using, like, the Angular boiler
plate, it by default caches things very aggressively.
So that's going to end up with behavior where
you deploy to Firebase Hosting and you think, OK, great,
my app is there.
You make some change, deploy again.
You'll go and you'll see the old version of the app,
because a service worker is sitting there having
aggressively cached everything, and you're
going to be, like, why is this not here?
And if you don't understand all the intricacies
of service workers, it's not going to be clear why.
So with Firebase, that can generally be an issue.
But with Firebase, it's particularly bad
because we make a ton of API calls on your behalf.
So if your service worker is sitting there caching those API
calls, things get really crazy.
So, for example, it will cache, by default, the read requests
from Firebase Database.
So you can read data from Firebase--
it'll cache some of that--
and then later you'll come back and you'll
have new data in your Firebase, and you'll
be getting back old data, because the service
worker is caching that.
So you need to be really, really careful about this.
And this happens across basically all the Firebase
services-- everything that uses client-side web requests, which
is all of them.
And so you need to go through and you need to explicitly say,
Google APIs should not be cached by your service worker--
most of the time.
Let Firebase do its job and don't let your service workers
start messing up those interactions
between our clients and our servers,
because, for the most part, we've already
thought of the offline interactions for our databases
and stuff like that.
JEN PERSON: Great.
Well that was really fun.
I'm so glad to have you on.
ABE HASKINS: Yeah, of course.
Thanks for having me.
JEN PERSON: Thanks for watching, and remember,
if you have any questions post them on social media--
Twitter, Facebook-- put them on Stack Overflow
with the hashtag #AskFirebase in it.
Thanks for watching.
See you next time.
[MUSIC PLAYING]
[LAUGHTER]