Extraordinary Apps with Firebase.

I'm James.

I'm the co-founder, and was the CEO,

of Firebase until we joined Google about six months ago.

I want to start on a little bit of a personal note.

Six years ago today, I moved to the Bay Area.

And the very first thing I did was come to I/O 2009.

A lot has changed in six years, and it's really great

to be back here for my second I/O, and this time,

speaking to all of you.

So we're going to have a brief overview of Firebase

and how we think about application development.

But before we go deep, I want to go broad.

So 10 years ago, if you were starting a startup,

you had to buy physical servers.

You'd call up Dell or HP and you'd say,

hello, I'd like a box with the Xeon processor

and a terabyte of RAM.

And they would ship you a physical server.

You had to find a colo facility and maybe, every now and again,

call the nice people at the colo facility

and ask them to reset your physical server.

And all of this seems unimaginable today.

The cost of these made them inaccessible to most.

And the time to set up, operate, manage, and maintain

seemed stunning, as well.

So it begs the question, if this looks crazy,

what are we going to look like-- today-- to software engineers

10 years from now?

If history is any guide, we're going to look antiquated.

Even though we've made huge strides, the tools

and the processes that we use to build software today

are going to feel clunky.

So where is software development going?

We think the developer's going to have more and more leverage.

You'll be able to do more with less.

Specifically, you'll focus on high level concepts,

like users, data, and tasks.

So how is Google going to help you do this?

Today, we'll be looking at some offerings

from Google Cloud Platform.

We'll be looking at an overview of Firebase,

going into a feature deep dive, and then we've

got some exciting announcements for you, as well.

So let's start with Google Cloud Platform.

Remember all those physical servers?

With GCP, you do not need them.

GCP provides compute storage, data analytics,

and several other services that help today's developers be

more productive.

I'm going to highlight a few of them.

First, is Google Compute Engine, or GCE.

GCE abstracts the physical machine

and gives you a virtual one.

This is also known as Infrastructure as a Service.

You pay nothing for the hardware and then you pay as you go.

With GCP, this is in one-minute increments,

which is pretty awesome.

An abstraction above that is containers.

So with containers, you don't have

to think about the operational concerns of a virtual machine.

Can we go forward in the notes?

Containers, basically, mean that you

can run software without thinking

about underlying hardware.

And with Google Container Engine,

you can run your code on a cluster of machines.

And that's done with the open source project, Kubernetes,

which Google released last June.

One level of abstraction above that, is Platform as a Service,

with App Engine.

With App Engine, you further don't

need to think about memory or CPU, OS upgrades.

You just give it your back end code,

and App Engine takes it, deploys it, runs it, and scales it.

And this makes developers significantly more productive.

And so GCP has some awesome offerings for service side back

end developers.

But what if you're a mobile developer or a web

developer working on the client side of your application?

Well, it turns out that Google has a service for you.

And that brings us to Firebase.

For those of you who aren't aware,

let's do a quick overview.

Firebase is a platform to help you rapidly

build really great mobile and web applications.

One of the first things you do when building an app is you

choose how to build its back end.

Firebase has three services-- user authentication,

a real time database, and static hosting--

to help you build your application without needing

to spin up servers and without needing to manage

complex infrastructure.

This saves you an immense amount of time.

But more importantly, it lets you

focus on creating a great user experience.

Your users do not care if the code to shard your database

is elegant.

They care if you're elegantly solving their problem.

Firebase has SDKs for iOS, Android, and the web.

This allows you to access Firebase directly

from your client.

With client side code, though, you often

need to structure and maintain it.

And this is why we've built deep integrations

with these great front end web frameworks.

If you want to access Firebase from a server,

you can use our server site libraries or wrappers

around our REST API in these languages.

And with our REST API, you can access Firebase from anywhere

you can do HTTP.

So how did Firebase start?

Well, 3 and 1/2 years ago, we saw some game developers

having some trouble setting up their back end infrastructure.

All they wanted to do was build a really cool game.

They wanted to make awesome artwork.

They wanted to grow their MAUs.

And they didn't want to think about the intricacies

of a distributed real time system.

So we started Firebase.

And today, this is one of our customers-- Roll20-- who's

built their entire game on us.

They are just one of 190,000 developers who are building

their applications on Firebase.

And Firebase has 1 and 1/2 million end user devices

sending data through us at any given time.

These are some of the customers that use us.

They range from ambitious startups

all the way up to large enterprises.

So that's a quick overview of Firebase.

Now let's look at our features-- authentication, database,

and hosting.

Data is the lifeblood of any application.

So we'll start off with the real time database.

Firebase has a NoSQL JSON database.

One of the most exciting features about this

is it does data synchronization.

Whenever the client device writes to Firebase,

we synchronize that data with the Firebase servers,

and then push it down to every other device who cares.

This is fantastic for this multi-device world

that we live in, where you pick up your smartphone

and put down your tablet and expect

to pick up where you left off.

It's also fantastic for this world of intermittent internet

connectivity.

When you go into an elevator or go through a tunnel,

you expect your application to still work.

And since, with Firebase, your SDKs

have a local view of the data-- a local copy of the data--

in memory on the device, it means your application

does exactly this.

But it's not just synchronization.

It's real time synchronization.

We push those updates to other devices in milliseconds.

And this allows you to build great, real time, collaborative

applications with Firebase.

Google Docs has set the standard for what you can do

with real time collaboration.

And now, with Firebase, you can build these great experiences

without needing a huge engineering team.

But instead of telling you, why don't I show you?

So we'll switch over to the camera.

And we're going to show an application called Talkboard.

Talkboard is built by Citrix, and it's

used in schools and companies with over hundreds of thousands

of users around the world.

So here I can select multiple boards,

and I'm going to jump into this one called

I/O. Now, with Firebase, these two devices

are connected over Wi-Fi.

When I write on one, it'll sync the data up to Firebase

and push it down to the other device in milliseconds.

So I can say, hi I/O. And I'll flip that around,

so we're all looking at the same thing.

I'll find the appropriate shade of blue.

Let's get a bit of a fatter stencil

there, go hi, I/O. I'll find a nice yellow,

draw a little sun up here.

So you can-- this is all vector data,

and it's all stored as JSON inside Firebase.

And you can see just how quickly those updates propagate.

And just how easy it is to build those collaborative features.

So go back to the slides.

Thank you.

[APPLAUSE]

There are a couple of great things

we should note about Firebase database.

The first is that it's accessible directly

from the client.

So you don't need to talk to a server.

The client can just go directly to the database.

Second-- and this is how easy it is to do so.

So this is actually some Android code.

First of all, we create a reference

to a location inside Firebase.

I'm doing that up top.

And then I can just call ref.setValue.

And I'm passing in a string there

that says, hi, I/O. This is all the code you

need to write to Firebase.

The Firebase database is just one JSON object.

So it's in a format that you're familiar with.

And it's in a format that all of the client side devices

that you work with already use.

It's schemaless.

And so it's super flexible, so you can structure data

how you like.

If you've already used Mongo, if you've already used Couchbase,

Firebase's database is going to feel really familiar to you.

And finally, every piece of data has its own URL.

JSON is a tree structure.

URLs are a tree structure.

So we've mapped every piece of data.

Every number, every Boolean, every string, to its own URL.

This gives you several great benefits.

First of all, it's intuitive.

So you can reference data with an absolute path

or with a relative path.

And it's all in a format that you know and understand.

Second of all, you can use those URLs as REST endpoints,

so you can manage and manipulate from REST, in addition

to the client libraries.

And finally, it's browser compatible.

So you can actually punch those URLs into a web browser

and you see a graphical view of your data.

And this is fantastic if you're debugging.

I want to talk a little bit about accessing Firebase

from the client.

Typically, when you build applications,

you're building them in a three-tier architecture.

So your device talks to an application server,

and that, in turn, then talks to a database.

As I mentioned, this isn't the case with Firebase.

We view application development as moving

to a two-tier model, where the device speaks directly

to the Firebase database.

And this gives you a couple of benefits.

First, it allows you to do the real time in the offline mode

that I mentioned.

But it also speeds up development.

There's no server boilerplate code

that's shuffling data between your database

and your application server.

When you add a feature, you don't

need to go and add new server code,