How's everyone doing today? [CHEERING] Is everyone super excited
about the new Firebase? [CHEERING] That sounds like kind of
excited, like, 9:00, 10:00 AM excited. Let's get really like,
6:00 PM concert excited. Like, everyone. How excited are you
about the Realtime-- [CHEERING] All right. That's a lot better. So I'm here today to
talk about two things. And those two things are
Realtime and offline. And it's kind of funny when you
talk about Realtime and offline together, because they're
kind of opposites. Because Realtime is a
fresh stream of data, and offline is data
that we usually get served from a stale cache. So getting them together,
it's not that easy. And trust me. I know. I once failed at a
startup doing just this. My startup's name was Kahhle. And we had one mission. And that was to
change the world. And we're going to
do that by building a collaborative
grocery list app. And if it was going
to be world changing, then it needs to be in Realtime. And you need it to work offline. So when we went
to build our app, we started with the back end. And we were like,
OK, we need a server. That makes sense. Then we need a database,
because we have store data, so let's do that. And then we had to build
a Realtime wire protocol just to talk to our
devices in Realtime. But then there's
more than one device, so we actually had to
talk to multiple devices. So we had to build a
synchronizing mechanism, so we could talk to all
the devices in Realtime. And then we also had
to deal with offline, so we had to build a local
cache on each device that could emulate a Realtime server. So we could serve the
changes to the device like it was in
Realtime on the app. And then after that, once the
app went offline and went back to online state, we had to send
that data back to the server, to the database, and then update
all the clients in Realtime. So a year later we realized,
oh my god, we haven't even built an app. So we built an Android app. An iOS app. And a web app. And the Chrome team
was like, guys, you only need to build
a progressive web app. And we're like, I'm
sorry, we can't do that. And they're like, why? And we're like, oh because
we ran out of money. So building a
Realtime offline app? It didn't have to be this hard. Because we could've
used Firebase. So Firebase is a suite of
integrated products designed to help you develop your
app, grow your user base, and earn money. And today, I'm here to talk to
you about the Firebase Realtime database. And the Firebase
Realtime database helps you build Realtime
and offline apps. And the way it works is, is
that every single time one device sends an
update to the server, that update is synchronized
across all devices within milliseconds. Today I'm going to cover
how you can store data, and then how to retrieve
that data in Realtime. And then saving data, and then
handling offline conditions. So let's start
with storing data. So we saw that when I had
my little mangly startup we had this big complex
back end infrastructure. And we were responsible for
building this, maintaining it, and hosting it. Well if we would
have used Firebase, we wouldn't have
had this problem. Because the Realtime
database is cloud hosted. And what that means is, is that
you don't have to build it. You don't have to maintain it. You don't have to host it. All you have to do
is build your app and the Realtime database
will do the rest. So how is data stored
in this database? Well it's just a tree
of lists and objects. So if you understand
what lists are, and objects are, and trees. Then you know how to store data. So let's take a
little visualization. This right here, is
the root of a tree. We can create a branch that
will be a list of grocery items. And then in this list, we
can have a set of items that all have values
that are a grocery list. Now if you stare at this
structure really, really hard, you might notice
something familiar. And that's that
this is just JSON. And that's because the Realtime
database is just one big JSON object, that you can
manage in Realtime. So if you're familiar
with JSON, that's exactly how you store data
in the Realtime database. And we call this a
NoSQL JSON database. So a lot of people
who are coming from a SQL background
or something, and they're not
familiar with NoSQL, they always ask me
a similar question. How do you structure
your app's data? Like, how should I
take this JSON data and fit it for my app? And there is just
one rule of thumb that you can really follow. And that's you can structure
your data after your view. So what this means is that
if our data structure is a list of grocery items, and
our app is a grocery list app, then we can take these
values and we just map them onto the view. And when you have
it set up like this, it makes it really easy to
read your data in Realtime. So let's see how we
can use the Realtime database to synchronize our
data across multiple devices. So this is the way we did
our back end with Kahhle. It was not really great. We never really
mastered Realtime. So what we would do is,
is we would send a request to our back end, and then
we would get a response. And then we could
render an item. And while that was just
great for one device, the other device has no
idea anything has happened. At all. Because we don't
have a connection from the database
to this device. So it's always left in
the dark to any changes. The Realtime database though,
has a persistent connection to every single device. So when data changes,
it knows what devices to send that data to. And we can do this using
the Realtime database SDK. So the SDK works on Android,
iOS, and JavaScript. And with this one
line of code, you can create a connection
to your database. And this is more than
just the connection. This database reference class,
it gives us a lot of control. Because database
references are a handle to an object or a list. So when you create a reference
to this piece of data, you have control over it. It allows you to read
this data in Realtime. So the first reference
you usually create is called the root reference. Because you're pointing at
all the data in your database. And likely, you don't
want to read all the data in your database because
you're a smart person. And you only want to
read just a subset. So let's say we want to
get at the grocery items. Well to do that, I can
create this child reference. And I can pass in the
key of my grocery items. And now, I have access
just to that list. And using Realtime events, I can
stream this data in Realtime. So the two types of events
I'm going to cover today are value events
and child events. So the way value events
work is you can attach them to this database reference. And so what you're
essentially saying is, is every single time data
changes in this location, send me an update. And we can receive this
update through a callback. And this callback is fired
with a data snapshot. Which is our
synchronized data set. And it's really
important to understand that we are synchronizing
applications states. We're not just
sending back updates. And to understand what
that really means, I set up this little
debug station. So the top, we're just
assigning a value event listener to our grocery list. And then below, we're
going to be logging the results to this console. So the first log
from the database is going to be
our list of items. So we could take this list,
and we can display on the view. Now, let's say a user comes in
and adds the item of coffee. What do you think is going to
happen inside on data change? So you might think that, well,
we added an item of coffee, we're going to get that new
item back in our data change. But that's not exactly
what's going to happen. What's actually going
to happen is, is we're going to get the entire list
including the newly added item. And that's because this is our
synchronized application stage. It's the true state of our list. And you might think, that
kind of sounds inefficient that, if I just add an item,
I download the entire set. Well, the Realtime database
SDK is a little bit smarter than that. And what it tries
to do is it tries to take delta events
from the server. And so only taking the
item that was added, and then piecing that together
with your local state. So it becomes
bandwidth conscious. So value events
are a way for you to synchronize the entire
value of an object or list when anything changes. But sometimes you want
a bit more control. You may not want to get the
entire object or list back, and you might just want to
get one thing at a time. So I might want to know
when only items are added. Or, if items have
been deleted, so I can display a fancy
little animation. And so that's where we
can use child events. So child events are similar
to value events in the sense that we can attach
them to a reference. But they provide us with more
than one type of callback. We can tell when things
have been added to our list. When the item's
value has changed. And we can even tell when
something has been removed. To see how this works, I have
that same debug screen up. And the very first
event that gets fired, is the child added events. And this gets fired for every
item, one at a time, that's existing in this list. So I'll first see it
for each item at a time. So as I go through,
we add an item, and then we render
it to the view. So this gives us single
control, one at a time. And let's say we go and
we want to remove an item. So if a user goes and
swipes an item off a list. Well this is going to
fire off child removed. And what this will do, is
that when this fires off, it fires off on every
connected device. So every device knows
how to remove this item. So let's say we change one
item, and we change from coffee, we want more coffee. And what that will do is it
will fire off child changed. And then we again get a
callback, and we know, this is the item that needs
to be changed in our list. And so this is a lot of events. And these provide you
a lot of control of how you synchronize your data. But sometimes,
you'll find yourself writing a lot of
boilerplate code to get this to work with common
components on your platform. So that's why, for Android
and iOS, we built Firebase UI. And what Firebase UI does, is it
takes these database references and it pairs them up with
a RecyclerView on Android. So you can take this
database reference, pass it to our Firebase
recycler adapter class. And then every single
time an event fires off, we will serve that change, and
bind it to your view holder. So it handles all
the eventing for you. And if you are an iOS developer,
it does the same thing with UITableViews. Every time something
changes, it takes that change and binds it to the
UITableView cell. And if you're a web fan,
we have integrations with pretty much every
major JavaScript framework. So whether that's Angular,
Polymer, Ember or React, we have integrations that
work with your style of flow. So that's how you
retrieve data in Realtime. But that's only
part of the puzzle. Because to trigger
Realtime events, you have to know
how to save data. So how would we add an
item to our grocery list? Well we know that
the initial reference points to the entire database. And that if you
create a child, it points to just a piece of
the database, just the list. Well we can again go and create
another child from that list. And that gives us an object
that we can save a value to. So in this case, we're creating
a child underneath the list. So a new grocery item. And we're giving it a key of
saying it's the second item. And we're giving it
a value of coffee. And the way this works is,
is that when one item sends this update to the
Realtime database, it's going to trigger
a Realtime event for each connected device. And then we're going
to render that device. Or render that
item onto the view. And this is what your data flow
looks like with the Realtime database. You save items, and
trigger Realtime events. And so we can keep our entire
application state in sync just through this pattern. But sometimes there
can be an issue. Let's say the other
device goes and they also add an item using that
same key of item_2. Well that's gonna
trigger a Realtime event. But, it's going to
delete the item of eggs, it's going to add
the item of coffee. And that's because we
used the same key name. And what this is
called is a collision. So we're colliding by
using the same key name. And the Realtime database
SDK has a really simple way of fixing this. So we'll go back and create
our grocery list to reference. And then rather than
creating an explicit child, we're to call this
method called push. And you can think about it
like if it was an array. And you're just pushing a
new item onto the array. Because what we're
doing is, is we're actually creating a new item
onto our list in Realtime. But this item we create,
it has a unique identifier. And this way when
we use this, we know that we will not be
colliding with any items that exist in the database. And when you know that you're
not going to have collisions, it sets you up to work offline. So when we were
building Kahhle, we had some serious
problems with offline. We were a grocery list app. And then people would
go to the grocery store. And then, turns
out, grocery stores are known for having
pretty bad connections. So they couldn't even use
their app in the store. And so when we went
to fix this, we ran into an issue by the fact
that offline really manifests itself in more than one way. So the Realtime database
handles offline in two ways. The first is
intermittent offline. And this works for
every single platform. So Android, web, and iOS. And this is like, if you go
into an elevator or a tunnel for a short period of time,
and your connection drops. Well the Realtime database SDK
puts a local in-memory cache on your device. So if the connection drops,
we can serve these changes through this cache. So it'll work offline
just as it did online. But sometimes you might be
going offline for a bit longer. And you might be
getting on an airplane, going through a hike
in the wilderness, or you just might be spending a
really long time in the grocery store. And in these cases,
you're likely going to turn off your phone. You're likely going
to restart the app. And when you do this, it's going
to clear that in memory cache. But the Realtime
database has a simple way of fixing this for
Android and iOS. And what it allows you to do
is just in one line of code, you can enable a persistent
cache on your device. And what this does is, is
if the user goes offline, and they clear out of the
app, their data will still live on the device. But what happens
when they go online? And what happens
if they were using the app when they
went offline, and they were writing to the database? Like, what happens then? Well the device, as we
know, stores this data in a persistent cache. And when it goes online,
it just sends that data to the Realtime database. And that merges the
changes on the server, and then sends a merged update
to every device so everyone can get back onto the same page. So that's how you do
Realtime and offline, but I wanted to talk
a bit about security. Because we're writing all
our code on the clients. So how do we keep
everything secure? Well the Realtime database comes
with a set of security rules. Which are a declarative
way to say who has access to what pieces of data. And this integrates with
Firebase authentication. So you can log in users, and
then secure data against them. And we're not going to go
too much into detail on this because Jacob Langar, an
hour ago, gave a talk all about Firebase and security. And if you want to see it, you
check out our YouTube channel that we just launched
the other day. Where all of the IO
videos are going to be on. And also a series of
screencasts called Firecasts which are
going to teach you everything you
need to know to get started with the new Firebase. And also tomorrow, you
should check out Zero to App, where four
of my colleagues are going to get on stage,
and live code the same app on Android, iOS, and web. Integrating the Realtime
database with Firebase Auth, and Firebase storage. So in this talk, we covered
storing data, retrieving it in Realtime, saving data, and
handling offline conditions. So now you know how you can use
the Realtime database to build real apps-- sorry. Now you know how to use the
Realtime database to build Realtime apps with Firebase. And if you build something, I
would love to know about it. So you can get started, and
then send me a screenshot, send me anything,
a gist or whatever of what you built. And I would
love to take a look at it. So that is what
we have for today, but for more
information on Firebase, you can check out
our office hours or head over to
our Firebase tents. And we'd love to
answer your questions. And just know that when
you build with the Realtime database, is that you're
getting the best of both worlds. Of both Realtime and offline. Thank you guys very much. [APPLAUSE] [MUSIC PLAYING]
