So, let's talk offline support. It turns out we don't live in a world
of perfect network connectivity. Your users live in a world of
elevators, tunnels, long plane flights and countries where roaming
data charges are crazy expensive and if you want your app to be great,
it should perform well even in situations where
your network connection might be spot... Wow, uh, this is taking a while. Um, how about let's roll the intro
while this is buffering, huh? ♪ (upbeat music) ♪ Okay, so if you're watching this video
because you're wondering how to add offline support to your app,
turns out that part's easy. On Android and iOS devices,
you don't need to do anything. Offline support is enabled by default. On the web, you'll need
to explicitly enable it and that's for a couple of reasons
I'll talk about later in this video but still, like a few lines of code. And if you're using the server SDKs, well, there is no offline mode. Honestly, if you're putting your server
into airplane mode, you might have bigger problems. I'm sorry he needs to go
on the plane with me. He's a licensed emotional-support server. And that's about it, just like that
you have offline support enabled. So are we done with this video?
Heck no. Let's talk about what it actually means
when you go into offline mode because that's probably
the more interesting part. So first off, let me back up and explain the general philosophy here
around offline support, which is that Cloud Firestore
is meant to work smoothly when your user goes offline for a few seconds, a few hours,
or maybe a couple of days. It's not meant to work
in offline mode forever. So if you're looking for a solution
that's offline first or you're expecting your user to stay offline for months
or years at a time and then occasionally go online
to back up their data, Cloud Firestore probably
isn't the right solution for you. So with that in mind, let's talk
about how offline support works. As your user interacts
with your app normally, they're downloading
all sorts of documents either through queries
or individual document fetches and those documents generally
stay cached on their device. So now let's say our user
goes through a tunnel and is disconnected from the internet. Well, they can still retrieve
any of this cached data that's been stored on their device, so your app will continue to work even if it sometimes has
to use old data. But how they get this data depends
a little on how you're fetching it. If you have a real-time listener setup, you'll receive this cached data
probably right away, but in the meantime,
your client library will still go out and try to fetch the most recent data
from the database. Now if you're online, you'll get back
that fresh data from the server and if that data is any different, your real-time listener gets triggered
a second time with this new data. But if you're offline,
this second callback, it just won't happen, and for a real-time listener,
this works just fine. I mean, if you think about it, these callbacks are designed
to be called multiple times. So getting called twice in succession, once with the cached data
and then again with the new server data should work perfectly fine
in your app. But if you're doing a single get call,
well here things get tricky. Get callbacks are supposed
to only be called once, so the Firebase SDK has to determine
whether you're offline or not and either give you the cache version
or try to fetch from the server first and then give you the cache version
only if that times out. And this is not as easy as it sounds because there are different levels
of being offline. I mean, there's obvious stuff
like airplane mode offline but then there's also, "I'm kind of going in and out
of WiFi range" offline, or "I'm going into a tunnel" offline, or "I'm connected to hotel WiFi but haven't accepted
the terms of service yet" offline. So depending on your situation,
you might get data back immediately or you might get it back
after several seconds. Joke's on you, hotel internet! This license agreement
is all the internet I wanted. Note that if you don't
like this behavior, you can always specify the source
of your data in the get call. For example, you can tell your app to always fetch the local cache data or to always fetch the server data. Oh, and one note
about fetching cache data whether you're doing it with a get call
or a real-time listener, is that you can query this cache data even if it's in ways that
you never queried it before. For example, let's say I ask
for the top 30 sushi restaurants in San Francisco, sorted by price, and then I also ask for the top 30
most expensive burger places. Later on if I go offline, I could still
ask for a different query like all restaurants in San Francisco
sorted by rating and that query will work
across my cache data. Now I won't necessarily get
the most accurate results. I'm only going to be able
to get at this cache data, so my top restaurants will consist of nothing but like expensive sushi and burger places but it'll still work. And then I can go ahead
and run any other query I want to against this cached data. So those are reads. Let's talk about writes. Now writes are interesting. Let's say you ask to make
a change to a document. Well, that data is stored locally
on the device, and, in fact, whether
you're online or not, your data will immediately
give the appearance that your change has gone into effect. Any real-time listeners
that are watching this data will trigger with your updated data. It's a little optimization
we do on the device so that from the user's perspective most writes look like they happened
with no latency. But, in the meantime, Firebase will still take
that write you've made and attempt to send it to the server. Now if you're online, then that write
will be confirmed by the server. Once it is, the Firebase library
will update your data for reals, it'll remove that pending write
and all is good with the world. But if you're offline, then that write
will stay there on the device and that's fine too. You can continue
to make changes to your data and these changes will all stay
locally queued up on the device. And anytime you want
to query your data locally, Firebase will take your original data
and just kind of replay all those queued up writes on top of it. Now you might think
this would slow down your app and you'd be right, but it generally
takes a few thousand writes for this slowness
to be noticeable to your users. So for the case where a user is offline
for the duration of a plane trip or a three day hiking trip
in the wilderness, you should be fine. But, like I said at the beginning,
don't think you can go offline for like several months at a time
and have a silky smooth app. So what happens when your user
goes back online? Well, all those writes
that you have queued up, will be sent over to the server. Now the database is smart enough
to apply these writes in the order that they were performed on the device. But when multiple devices
write to the same document, Firebase simply goes with a strategy
with the last write it receives wins. So, let's say my friend Pam and I are both writing
to the same restaurant document, I hop on a plane, put my phone
into airplane mode and I change my restaurant's name
to Todd's Tacos. Now I'm offline, so my change just
stays queued up on my local device. An hour later, Pam decides to change
our name to Pam's Pozole. She's online and so her changes
are made right away. A few hours after that, my flight lands, and I turn on my network access again. My changes are then sent down
to Cloud Firestore. Now when Cloud Firestore
receives my changes, it will overwrite Pam's, and our restaurant
will now be named Todd's Tacos, which is the much better name, even though technically speaking
my changes occurred before Pam's. Now honestly, this simple
conflict resolution is probably good enough
in the majority of situations. But if you do need something
more sophisticated than that, there's some strategies you can try
with security rules or Cloud functions and may be that's something
I can cover in a blog post one day. Make sense? Okay, let's talk about a few
lingering questions you might have and then mention a few gotchas. Okay, first question:
how large of a cache do we actually keep
to store all that offline data? So now this is something
you can change in your settings but the default value is large enough that you probably won't need
to worry about garbage collection but also small enough that
your users probably won't notice. I mean, here's the thing, all this data that you're loading
from Cloud Firestore, it might seem like a lot, but remember that we're primarily
dealing with strings, numbers, and JSON-y looking objects. These pale in comparison to binary data like images, sound,
and compiled code. Like if I cached 500 restaurant reviews
of 200 words each, I'm still probably talking about
say two-thirds of a megabyte. If I cached about 3,500 reviews, then it would be at the size
of a single photo. Still, if you're streaming
in data like mad, you will run up against
this maximum cache size and when you do we follow
the least recently used strategy. You probably hear this called
an LRU cache because as engineers we all love acronyms. So you're telling me it's an initialism and not an acronym
because I say the letters out loud? Well it just so happens I call it
a "Laroo" cache, so there. An LRU cache works the way
its name suggests. When we're deciding what documents
to remove from the cache, we'll look at the least
recently used ones and by used here I mean anything
from accessing it in a query, to writing to it, to fetching it directly. Whatever document
has gone the longest time without being accessed, that gets booted from the cache and we keep doing that until
you've got enough space again. Now as far as pending writes go,
those are never expunged. We'll keep them around
until you get connected again because that's important information
we don't want to lose. Okay, second question: why are you seeing
a lot of duplicate data calls? So there are two times
when you might expect your real-time listeners to get pinged
with duplicate data, particularly when you're online
and everything is working fine. First off, when you activate
a listener on a document, you get back
the cache document right away but then a short while later you get back the version from the server. Often this will be the same
as the cache version and you'd expect your listener
to get triggered twice, but it doesn't. Second, when you write to a document,
that change is made locally and triggers any real-time listeners
on that document, and then a short while later, when that change
has been confirmed on the server, you basically get back a copy
of the "new document" that's exactly the same
as the local version. But again, your real-time listener typically doesn't get triggered
that second time. So now in both cases,
Firebase is storing some metadata about your snapshot, fromCache, to indicate if this data is being served
from the cache or not and hasPendingWrites to indicate if this data still needs
to be written to the server. And, by default, Firebase
is smart enough to know that if your data looks
exactly the same but only this little bit
of metadata has changed, then it won't ping your listener
a second time and that's why you're not getting
a lot of duplicate calls. And most of the time this is probably
the correct behavior for your app. Now, you can change
this behavior if you want-- like maybe it's really important
for you to show on your UI that a write has been confirmed
by the server-- but, in general, I'd recommend
sticking with the default unless you have a good reason not to. Okay, third question:
what's up with the web, why is an offline mode enabled by default? That's two questions, should we--
All right, it's two questions, but we've agreed
we're going to answer it anyway. So probably the biggest reason web offline mode isn't enabled by default is that it's much more common
to see web pages available on shared devices, like your everyday
public library computer, and you don't want to be in a situation where you're accidentally caching
sensitive user data. So by making sure
it's not enabled by default, we're giving you a chance
to really consider whether this is what you want
and maybe potentially add one of those "Hey remember my data
on this device" kind of checkboxes before you go ahead
and enable offline mode. But the other reason is
that you still have to deal with issues like browser compatibility
and offline support in multiple tabs, which actually is something
we support now but only in an experimental flag
in the settings. So you might have noticed that,
unlike native mobile apps, when you turn on
offline support on the web it returns a promise that tells you if you are able
to successfully activate it. Now, if it doesn't succeed, then you get back
an error object explaining why either because it's not supported
by this browser or the app is already
open in another tab and you haven't enabled
that experimental setting. And then you can do something
like display a big old message box telling the user that they already
have this app open in another tab and they should go there, or they should go
and use a different browser. Okay, finally, let me call out
a couple of gotchas to look out for. First off, with document writes,
the biggest issue I've seen out there in the wild is that the callback to a document write doesn't get called until the write has actually
been confirmed on the server. And this is a big deal,
because I've seen a lot of cases where developers will bring up forms to add a new document
or edit an existing document and then dismiss that form
in the callback. They test this while they're connected
and everything works fine. But if their user goes offline,
this callback isn't called, the form never goes away, and it looks like the application is hung because your app is still waiting
for a response from the server. Now, I'd say most of the time
the right thing to do here is take that code you've put
into this callback and simply call it immediately
after your write. Remember, thanks to some clever work
in the client library, Cloud Firestore acts as if the data
in your write is applied immediately so you don't need to wait for a callback to be working with fresh data. Code that lives in these callbacks
should be reserved for the times when you want to be sure your write
has been confirmed by the server and it probably shouldn't
be blocking anything. Gotcha number two: as we noted
in the previous episode, transactions will fail
when you're offline, and this is kind of an intentional
feature of transactions. Remember, the point of most transactions is that you want to make sure you're dealing with up-to-date data
from the database-- when you're doing things
like transferring money between a checking
and a savings account-- and honestly this is just
one of those situations where it's safest to just fail rather than try
and get overly clever here. Batch writes on the other hand,
don't have this issue, go bananas. Finally, gotcha number three: you know how we say that every query
in Cloud Firestore is fast because we index everything? Well, that's not actually true
when it comes to the offline cache. On the cache write now
there are no indexes, so queries can take some time. The speed here depends a bit
upon the device you're using, the size of your documents, and the number of documents
in your collection that you've got to go through. Now again, if you use the cache
the way it was intended to be used essentially as a fallback
for new user goes through a tunnel, say, you're still okay. I mean, even a slow local search
is going to be faster than, say, trying to download data
over a nonexistent or flakey connection. But I've seen situations
where developers will download hundreds of thousands of documents when their app first starts up, then try to perform all the rest
of their fetches only through the cache either because they think
they'll save time or billing costs, and, in general, they just end up creating a worse experience
for their users. So this is not a strategy I would
recommend for most apps. So there you go, that's just about
everything you've ever wanted to know about offline mode in Cloud Firestore. Like I said, offline mode
is already enabled in native mobile apps, and the default behavior
generally does the right thing, so there's not really
any work needed on your part to ensure a good offline experience. But I still think it's probably
a good idea to know what's going on underneath the hood, or at least appreciate all the work that Cloud Firestore is doing for you. Good job there, Sport! Thanks for watching,
and we'll see you soon on another episode
of "Get to Know Cloud Firestore." ♪ (upbeat music) ♪
