[Music]
hi everybody thanks for joining me
virtually in this online extravaganza so
I know the original title of her talk
was what's new in firebase four back in
game developers but hey spoiler alert
we're gonna talk about cloud firestore
what it is why you should care and maybe
why that database engineer next to you
just got really excited so as you may
have heard firebase has a number of
tools to make it easier for you to get
your game up and running the general
idea here is hey why don't you let us
take care of the boring infrastructure
work and you can focus on other tasks
like making your game fun which you know
probably should be your top priority so
we provide services like a firebase
authentication which makes it super easy
for your user to sign into your game
from a variety of different providers we
have firebase hosting the idea with this
is we can make it easy for you to get a
website up and running quickly on a
global CDN that's SSL by default and all
that great stuff and this is really nice
if you have like say a one-off marketing
site for your game that you want to get
hosted really quickly we have cloud
storage which is a powerful yet simple
service for storing large binary objects
and this could be user-generated content
like screenshots or videos or content
you provide like say chunks of post
install game data there's cloud
functions for firebase which lets you
essentially run back-end code without
needing to stand up any servers on your
own and then we have our data bases for
storing data in the cloud
now the real time database is the one
many developers have heard about this is
firebase is flagship product back when
it was its own independent startup and
it is still a great product the idea
here is that if the user changes the
value on one device our SDKs and servers
automatically update that change on
every other device that's listening to
that value and yes I should note that
real time here means something a little
different than what you game developers
are used to it's a few hundred
milliseconds of latency so probably not
suitable for powering your first-person
shooter but you totally could use it to
drive say a bingo game in fact here's a
fun fact the real-time database was used
to power low Torreya this is the bingo
light game that ran as a Google Doodle
this ran on the Google front page in
over a dozen countries and the real-time
database took care of like the
matchmaking the calling out of the
square showing your opponent's moves in
real time and declaring a winner and
what's really neat is this game went
from zero players to
millions like literally overnight we
started displaying it on the Google
front page turns out Google that's a lot
of traffic who knew and the real-time
database just got a handle bill there
are no panic calls to engineers or
anything and in fact we have a really
nice blog post going into detail around
how the engineering team did all this
and I encourage you to read it for more
information and that's nice but for many
native app and web developers we've
introduced the next generation of the
real-time database a product known as
cloud firestore and all in all it's been
a really well-received product except
for the fact that there are no client
libraries for c++ or unity until now or
i guess a few weeks ago we announced
that it's available as an alpha release
and I am going to talk more about that
alpha tag in a minute because that's
kind of important now maybe some of you
are super excited about this already and
are like running off to build your own
like composite indexes or what have you
but for the rest of you who aren't big
database nerds you might be asking
yourself well I guess this is good news
and all but what does this really mean
and why should I care so let's back up
and explain cloud firestore like the
real-time database is part of a family
of databases known as no sequel
databases and if you want the overly
simplified version of what that means
well think about a traditional database
you have like a bunch of tables each of
which stores types of highly structured
data and you can join these bits of data
together using a query language called
sequel and you can do a lot of fancy
stuff here right you like you can merge
in different pieces of data or like
calculated pieces of data from all sorts
of different tables and while that's
pretty neat performance can be quite
variable this query could take a long
time or a short amount of time depending
on like how much data I have how its set
up and what kind of query I'm asking for
now no sequel databases are different in
a few important ways one thing you'll
notice is that they tend to be a little
more loosey-goosey with their data
officially this is known as being schema
lists and it's often seen as a good
thing like it gives developers the
ability to iterate a lot faster on their
underlying data without having to worry
about sort of backfilling every change
they make to all their older records it
also gives you the ability to store data
that's similar but not exactly alike you
can see here I'm storing a bunch of
characters together in the same
collection and yeah shows are similar
but I can go ahead and add like a spell
book for my mage and a battle cry for my
fighter and a set a lot pics for my
thief and our database isn't going to
complain that our data structure
exactly alike from one character to the
next it can just kind of handle this but
I think the biggest difference with a no
sequel database is the fact that there
is no sequel queries tend to be a lot
simpler you don't get sort of all those
fancy joins that merge all that data or
calculated data together and this means
you'll often see things that look kind
of strange or unusual at first like
having copies of the same data exists in
multiple places now some of these quirks
particularly this concept here which is
known as denormalized data kind of freak
out longtime sequel developers at first
but in the long run there are some
really nice trade-offs that make some of
this weirdness worth it for starters no
sequel databases can scale horizontally
and this is really nice this basically
means that as your data set gets bigger
and bigger you can just kind of throw
more and more machines at it and it will
go ahead and simply serve its data
across all these different machines and
that's really helpful in a cloud hosted
environment like I don't know say just
to pick one the Google cloud platform
where we have tons of servers we can
just flip on and off as your database
needs it your database simply grows and
expands onto these different servers
kind of behind the scenes and without
your even knowing that that we're doing
all this work for you by contrast
traditional sequel databases tend to
scale vertically this means that as your
dataset grows you need to find bigger
and bigger computers to host them on and
that can be problematic for one thing at
some point you're probably going to run
out of massive supercomputers to run
your dataset on and it also means that
every time you need to switch out to a
bigger and faster supercomputer there's
probably going to be some downtime and
often with no sequel databases you will
find that performance is better in fact
one thing we are fond of saying in the
cloud firestore world is that query
scale to the size of the results set not
the size of the underlying data set and
what does that mean that means that if
say you had a game where you were
storing user generated puzzles in cloud
firestore and you asked the database
hey send me the top ten active levels in
the united states sorted by rating that
query would take the same amount of time
whether you had to search through 300
records for 300 million right no matter
how large that underlying data set gets
this query will basically take the same
amount of time and that's pretty great
because it means you generally don't
need to worry about having to like
restructure your database for
performance reasons as your game gets
more and more
popular so let's go over a few other
features that makes Claude firestore
generally enjoyable to work with for
starters the data structure model tends
to be pretty pretty nice to work with
particularly compared to something like
the real time database or other no
sequel databases all of your data tends
to be stored in documents and
collections now documents you can think
of as well
documents that contain key value pairs
and the values of these things can be
anything from like arrays to strings to
floats to JSON II looking objects to
even small amounts of binary data now
these documents can be up to one
megabyte of data for each document which
actually is pretty large given that
you're mostly dealing with like texts
and numbers and JSON II things here now
these documents are stored in
collections which are as you might
suspect collections of documents and
these documents can and often do point
to sub collections that contain other
documents which might even point to
other sub collections and so on and so
forth now one important note here is
that all queries are shallow meaning
that you can grab a document without
having to worry about grabbing all the
data underneath it and that means you
can structure your data hierarchically
in a way that makes sense geologically
without having to worry about sort of
grabbing tons of unnecessary data every
time your user requests one of these
documents on the top here cloud
firestore has really robust offline
support built into all the client
libraries so the SDKs will catch your
data automatically as you grab it from
the server and then if your user were to
like hop onto an airplane turn on
airplane mode they would still have
access to all the data that's cached on
the device which means they can keep
playing your game and you can go ahead
and query any data that's stored in your
offline cache in addition any rights
that your players make they get queued
up on the device and then as soon as
your user goes back online they're
delivered to your database in the order
that they were recorded so another
gameplay session data gets lost cloud
firestore has support for simple
one-time fetches of your data which is
probably what you're used to if you're
coming from a more traditional database
and a lot of developers start using
cloud firestore this way but you can
also add real time listeners so that
your client gets notified right away
when a value enter document changes and
that's pretty neat right like you simply
tell the library hey I want to listen to
the results of this query and Claude
firestore can send you updates when
these values change which means you're
have to deal with any of that
pull-to-refresh nonsense
your new data just appears as soon as
it's available which is great for
situations like multiplayer games when
you want your game state to be updated
after user has taken their turn caught
fire store has multi region support
which means that we can store your data
in different locations a few hundred
miles apart from each other
and this is really nice from a
reliability standpoint because if like
say some kind of radioactive lizard or
what-have-you
were to take an entire city offline your
data would still be accessible from
these other regions but at the same time
it's strongly consistent which means
that the data you're retrieving is the
latest version of the data that's been
written to the database sort of no
matter which region your client
originally pinged and I'll be honest
having the sort of multi region support
while also being strongly consistent is
this like really amazing a difficult
problem that we've solved behind the
scenes for you and honestly I don't
think people really appreciate how cool
this is so trust me when I say hey this
is a pretty neat problem we solved
caught fire store also has support for
atomic transactions if you want to make
sure some other client isn't messing
with your data at the same time you are
I don't have a slide for that but I know
it's a thing people care about so I'm
gonna mention it here and because we're
all making games and we know we can't
always trust our clients we also have
support for cloud functions and security
rules now security rules are rules that
you define that will reject requests
from the client either where your client
is asking for data they shouldn't be or
they're trying to write data that
doesn't look the way you expect but if
you need more sophisticated controls you
can use cloud functions these are
serverless functions that run in the
cloud in an environment that you control
and trust and that means you can make
sure this functionality is consistent
across all your clients and more
importantly you trust the changes that
they make to your database so I know
we've talked a lot about cloud firestore
are a real-time capable no sequel
database that lives in the cloud and you
might be asking yourself well women
how's this compared to the firebase
real-time database the real-time
database that lives in the cloud and to
be clear you don't actually need to
choose one or the other you can totally
use them both within the same project
depending on your needs but if you
needed to kind of compare and contrast
the two I generally like to think of
cloud firestore is like a heavy duty
version of the real-time database in
general I think it can handle more
complex data better this is kind of my
personal opinion but I think the data
model is easier to work with you have
more powerful querying capabilities
your transactions are a little more
sophisticated it scales even better than
the real-time database and you have
multi region support for better
reliability there are a few things that
the real-time database does better
though it tends to be somewhat faster if
your customers are located in North
America and has built-in support for
presents this is something a lot of game
developers care about sort of having
players find out if their friends are
online now there are workarounds for
this in cloud firestore but it's sort of
not natively built-in and it's not as
elegant as what's in the real time
database also the pricing model is
different in the real time database your
costs are primarily based on the amount
of data that you're sending back and
forth to your clients
cloud fire stores costs are primarily
based on the number of read or write
operations you perform so in general the
real time database is going to be a
little more cost effective when you have
lots of small operations think of a game
like bingo or poker where your clients
are very frequently sending across
little pieces of information like call
rays or you know b14 cloud firestore
tends to be more cost effective when you
have smaller amounts of maybe large
operations think about like an
asynchronous drawing game we are
probably sending across like a large
chunk of JSON data that represents the
players drawing or even like a
turn-based word or chess game where your
players tend to think for long periods
of time before they take a turn they're
not performing that many operations but
I would also say don't get too fixated
on price there's lots of ways cloud
firestore can make your life easier and
you know your engineering time cost
money too if it takes ten extra
engineering hours to save yourself like
18 bucks and server costs that's
probably not the right great trade-off
use your engineering time wisely these
people tend to eat fancy snacks so how
would you use cloud firestore in real
life let's look at a few potential
real-world scenarios one of the most
simple use cases saving your players
game to the cloud right your users want
to play their game on multiple devices
and cloud firestore makes it really easy
to save your game state to the cloud
just right your player state into a
document write that document to the
database and any other client listening
to that value can grab the latest
version and make sure your player's
progress is reflected everywhere that
they're playing your game I should also
point out that storage and cloud
firestore is relatively inexpensive
particularly compared to the real time
database so you could go ahead and save
a few versions back so that when your
player frantically calls customer
support and they're like ah
my game you have the option of restoring
them to an earlier save game another
good use case for Claude firestore is
like shared game state think about a
turn-based word game or drawing game
it's really easy for for starters for
your clients to go ahead and query for
games that they're participating in and
then every time your player wants to
take a turn you can just record that new
game state in this shared document that
all the appropriate players have access
to and then thanks to the magic of
real-time listeners those other players
clients can get updated as soon as the
game state has changed so they know it's
their turn and if you want extra
security rather than having your clients
update this document directly you can
have them relay their desired move to a
cloud function remember these are our
service functions that live in the cloud
this cloud function can then validate
your players move make sure everything
looks legit and then it can perform the
work of actually updating your shared
game state which then gets sent to your
other players and also thanks to our
integration with firebase cloud
messaging you could send a notification
to your other players so that even if
they don't have your app open at the
moment they can still get alerted that
it's their turn daily challenges these
are probably another good example these
things are sort of decent chunks of
content that you're going to need to
send to all your clients every time they
sign in I know there's a lot of like
role-playing games puzzle games
crossword puzzles and so on that have
daily challenges and this is data that
could easily be stored and served
through cloud firestore user-generated
content could be a good use case - again
for large binary objects like videos or
screencasts I'd recommend using cloud
storage but think about any kind of like
puzzle game or platformer game or users
are creating their own levels this is
probably data that you're storing as
JSON data and these could work nicely in
cod firestore and then again you could
run queries like find all puzzles
created in North America sorted by
rating or find most recent puzzles or
find all puzzles by a particular author
I think the most interesting use case
particularly for a lot of larger and
more established companies is to use
cloud firestore as a real time globally
scalable caching layer on top of your
current infrastructure let's think about
an airline for a second these airlines
they've got like there are 30 year old
legacy servers with a bunch of business
logic and regulatory compliance team
built in they probably just can't like
swap everything over to a brand new no
sequel database right but
same time maybe they want a nice modern
application infrastructure that can like
handle millions of queries and have
real-time updates and nice offline
support and all that fancy stuff right
well what these businesses can do is
copy over some of their data to a cloud
fire store instance that makes it really
easy for these clients to you know do
searches like let's find ticket prices
or get flight status information or that
sort of thing and get those updates in
real time while leaving your legacy
server to handle important things like
say purchasing a ticket stuff that
probably still needs to go through that
original server now if you've been
watching this presentation I'm guessing
you don't have an airline to run but
maybe you do have an MMO a collectible
card game or a role-playing game where
you have a ton of data whether that sort
of gameplay balance settings or player
profiles or what-have-you that your
clients are going to want to read in on
a regular basis and again that's a lot
of clients that are constantly hitting
your servers so consider putting cloud
firestore in front of that right your
clients can go ahead and query the data
that you've pushed a cloud firestore
while leaving your original server free
to handle important things like you know
player transactions or user purchases
now with all that being said maybe
you're super excited to start building
with cloud firestore but I do want to
talk about that alpha label here while
the cloud firestore back-end service has
been around for quite a while and is
used in real production apps these new
client libraries aren't very new and
haven't really been battle tested yet so
expect bugs there will probably be some
we know that some advanced features are
missing from the ud sdk some of the more
sophisticated queries aren't available
yet and things like numeric transforms
aren't supported yet and we fully expect
that the API surface will be changing
over the next few months so you are
gonna have to rename your methods at
some point when you update your client
libraries so I would encourage you to
start giving these new libraries a try
see how they would fit within your games
infrastructure and of course send us
feedback but maybe hold off on moving
your entire business to a cloud fire
store based one until we're you know
like a few more months along so with
that scary disclaimer out of the way I
hope we've gotten you at least a little
interested in using cloud firestore in
your latest game if you want to find out
more about cloud fire store or any of
the other services we offer head on over
to firebase google.com slash games and
check it out and as always thanks for
watching
[Music]