JAMES TAMPLIN: Hi everyone, and welcome to Developing
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,
or add new tests to that code.
So it really does speed up development.
And then you're also offloading scaling to Firebase.
So you don't need to re-architect your server
code to scale.
Firebase already guides you into a pattern
where your operations on your data scale linearly
with the size of your data set.
This is how most high scale production
apps are written, anyway.
And you're doing it from the very beginning.
With a two-tier architecture, you
may be asking, how do I run server code,
if I want to run some trusted code?
Or if I want to do some heavy lifting that I don't
want the edge phone to do?
Well, you can just hook a server up the Firebase database
directly.
And you can also connected with third party APIs.
And you may be thinking to yourself out
in the audience, OK, that's great.
But if my device is talking directly to my Firebase
database, how do I secure it?
And the answer is with our flexible rules language.
So this language lets you define how your data can be structured
and who can access it.
These live on our server, and here's an example of them.
So here are my rules language.
I'm saying the foo node can be read by anyone,
it can be written by anyone.
And then I have a validate rule that enforces the schema.
So it's got to be a string and it's
got to be less than 100 characters.
These are all in one place.
They're stored in the Firebase servers, and they're all JSON.
Again, you can upload them with our CLI
or edit them directly at Firebase.com.
So we've taken a look at the Firebase database.
Now let's move to Firebase authentication.
Most every app has the concept of a user.
Unfortunately, the first thing you
do when you set up set up an app is
have to write a user authenication system
or fight with OAuth.
With Firebase, we enable you to easily implement
email and password and then connect with third party
providers, like Google, Facebook, Twitter, and GitHub.
And you can do this really easily.
This is the code in JavaScript implement Facebook login
with Firebase authentication.
I create a reference, as we saw earlier,
and I call ref.authWithOAuthPopup
and I pass it to string Facebook, give it a callback.
That's it.
I can change that to Twitter.
I can change that to Google.
And that's all I need to do to implement log
in with a third party provider.
Really is that simple.
So what if you're asking, how do I actually integrate it
with my existing user system?
I already built one.
And the answer is, you can easily
use one of our eight server side libraries to integrate.
You just generate a JSON web token, another open standard,
and that'll tell Firebase who your user is.
But our Firebase authentication also
works with our security rules that I just mentioned.
This enables you to build secure applications with a user
authentication system.
So let's say we have a users node.
$uid basically specifies that we can interact with any user
entry in the user's node.
It's saying that anyone can read a user's profile,
but only the person logged in can modify their own profile.
It's that easy with just a few lines of code.
Finally, let's look at Firebase hosting.
It's production-grade hosting for developers.
So Firebase hosting was designed for mission-critical sites
and apps, and we built it for reliability and scale.
It runs some great sites, like Firebase.com, Angular,
and the Polymer team user, as well.
It's backed by global CDN, so you get pops around the world.
It's SSL by default. We even provision SSL cert for you.
So you don't have to go off and buy the $150 cert.
And it has custom domain support so you can hook it up
to your own custom domain.
You just go into your terminal, go to the directory you want,
call firebase imit.
And then you can call firebase deploy
and it'll push that content up to your own Firebaseapp.com
URL or your own custom URL.
So we've seen Firebase authentication real time
database and Firebase hosting.
Now let's take a look at some of the customers who use Firebase.
Instacart is one of the rising stars in Silicon Valley.
They let you do grocery delivery from your mobile app
to your door in hours.
And they've been using Firebase since the beginning.
They've raised over $300 million from top-tier VCs
and they use Firebase for a number of things.
You can collaboratively edit your shopping cart
with your roommate or spouse.
You can talk to your shopper while they're in the store.
And you can also see where your order is with their live order
location tracking.
The next customer's a little bit of a different profile.
So Sky News was the UK'S first 24-hour news network.
They're based in London.
They have new bureaus around the globe.
And on May the seventh, the UK held general election.
For those of you unfamiliar with British parliamentary
procedure, until this year, an election
would be called within a five-year window.
And as soon as it was called, then six weeks later,
the election happened.
So this six-weeks election cycle makes some democracies,
I know, feel like a walk in the park.
Sky News used Firebase to synchronize election data
from their iOS app, their Android app, and their web app.
So that on the night of May the seventh,
and the morning of May the eighth,
the millions of people from around the world who tuned in
to watch the most-watched election in UK history
got the updates with Firebase.
We're really excited that this software was
built in a matter of weeks by their team
and achieved this scale.
Next up, we have Citrix.
So Citrix uses us in some of their flagship applications
like GoToMeeting and GoToAssist.
Well one of their newest applications uses us, too.
Today, I'm excited to welcome onto the stage
Gus Pinto, senior director at Citrix,
who's going to tell us a little bit about how Citrix
is using us in Concierge.
So we'll switch over to the--
GUS PINTO: Good morning, everyone.
I'm really jazzed to be joining the Firebase team and James
here.
We built a wonderful relationship
that expands on the original relationship we'd
had with Google.
You see, Citrix-- we have a pretty mission-critical task
at hand.
OK?
We power over 400 million workspace users
every single day.
And one thing that we did notice is
that the vast majority of our mobile users are going mobile--
are getting the work done on a mobile workspace.
And it really dawned upon us that the vehicles in which we
support customers today on mobile devices is antiquated
and it's really, really bad.
I mean, to the point of being frustrating to the most part.
Things like-- the best things that we can come up
with sometimes was just putting a button in our apps
that sends an email form to somebody,
when the problems that we have are happening right now.
That's why we've created Concierge.
We really just re-imagined the communication flow and the way
companies connect with their customers and employees.
And we launched it two weeks ago.
And beyond our wildest expectations,
we sold out our tech preview in the very first day.
And quite honestly, we couldn't have done that without Google.
Now we do leverage a lot of components of Google
across our technologies.
In the case of Concierge, we use WebRTC and Chrome.
We have an SDK for Android, we leverage Cast.
But at the very heart of Concierge--
and really what enabled us to get here-- was Firebase.
I say it's in the heart of our product
because it's the ticking component that makes everything
flow within our product.
From user authentication, as James
alluded, to the real time data from end to end.
We had to reinvent the inbox for agents-- our chat
communication-- and so many other components all the way
to signaling for WebRTC.
We really rely heavily on Firebase.
And I could just spend the time here telling you about this.
I'd rather show you what this looks like
and what we've managed to accomplish
with our partnership.
So I think there's nothing better than to truly show
a live product.
Nothing more dangerous and better
than to show a live product.
So we brought a customer product to show you guys.
And it's from a company called Modernizing Medicine.
And what those guys are doing in their own environment,
in the medical space, is reinventing and reimagining
how physicians interact with patients.
And they're doing it from anywhere
and bringing the power of electronic medical record
systems to mobile.
Now what I want to do is fire it up here.
And hopefully, you guys can see it good.
I'll log in.
Now with Concierge, what we've done
was-- as part of reimagining how we would support customers
on the go-- was, first, something
that actually Google's very keen on, which is contacts.
Trying to get support in today's apps--
whether it's the email form, or going out of your app,
scrambling, finding a 1-800 number,
calling somebody, and eventually being frustrated,
giving up, and going and bashing them on Twitter--
it's rather frustrating.
So we figured that the place to start-- it's
what makes our product really smart, which are the apps.
In the case of Modernizing Medicine, what they've done
is they've integrated Concierge, which
is a simple SDK you plug into your app.
And with one line of code, just fire up
an entire suite of technologies that allows you to communicate
real time with your customers.
And in the case of real time, we mean with the push of a button,
you can get audio-- like a normal internet call
right within your app-- a video--
so you can see the representative that's
helping you in real time, or just a simple chat,
if you're not fond of having a conversation through audio
and video.
So what I'm going to do here is go ahead and start a new visit.
And simple things-- like, say, I'm a physician,
the application has been updated,
something moved and changed, and I don't know what it is.
And I'm a doctor and I'm kind of lost.
And I don't want to go to a consultation with my patient
and be like, I don't know what's going on.
JAMES TAMPLIN: I didn't know you were a doctor, Gus.
GUS PINTO: I am a doctor to make believe.
JAMES TAMPLIN: OK.
You're like Doogie Howser.
GUS PINTO: So what I'm going to do here
is I started a new constultation,
but I forgot, with this new UI, how to properly document
this visit.
So what the guys from ModMed have done
is they embedded our SDK into their product.
It took them less than 20 minutes.
Trust me, the developer of the product is here in the audience
and he can hold me up to it.
And with the push of a button, it
comes up on their own UI that confirms that you actually
want to get support.
And what that does-- when I press this button,
it goes out there and establishes a connection
on Concierge.
And as you can see-- can we switch back to the Notebook?
Thank you.
That puts, instantly, a new session
within our inbox, where the ticketing system happens.
And James will be my support agent.
JAMES TAMPLIN: I'd be happy to.
So I'll go ahead and answer the call here.
And I've got an incoming call.
So I'll accept.
GUS PINTO: So voila.
So right within our app, we have a live support agent.
Now can we switch back, real quick, to the [? Wolf ?].
Now you see that we can-- let me hit OK here to confirm.
Now we're sharing my screen.
So you can see that James-- I can just
move him around the screen, and it's really swift.
And he can hear me and I can hear him.
But one thing that happened here was just
getting the communication flow between the customer
and the company was not enough.
Tools to get proper support for mobile customers
really didn't exist.
So we had to create something new.
And we call that Copilot, which is the ability for you
to share everything that's in the screen of the customer's
computer in real time, whether it's
an iOS device or an Android device or a web app.
As well as the camera, because most of these devices
have a camera.
And sometimes the problem's not necessarily in the app itself,
but in the real world and something
you want to interact with.
As well as information, like what the device version is
and what the battery level, what the Wi-Fi, and things
of such nature.
JAMES TAMPLIN: So how can I help you today?
What seems to be the problem?
GUS PINTO: So I forgot how to document
a session with this patient.
And since the UI changed, I really don't know how it is.
JAMES TAMPLIN: You're a terrible doctor.
GUS PINTO: I'm a horrible doctor.
JAMES TAMPLIN: So if you want to start an exam,
what you're going to want to do is click this exam button here
in the upper left.
And I'll just highlight that for you.
GUS PINTO: Cool.
So you see that right on the iPad, whatever he did,
he could draw on my screen and guide me to completion.
And we call that feature Touch Assist.
He can actually see where I tap on the screen in real time.
So if we switch back to Notebook,
he can see the drawing.
You can see he can simply clear the drawing.
JAMES TAMPLIN: Cool.
So I'll clear that with the eraser.
GUS PINTO: Once I touch where I need to touch-- and all
the touches that I do-- I perform-- they show up
in real time.
Including any updates I make to the application.
JAMES TAMPLIN: Just going to give her a little hair.
I could totally be a doctor, too.
GUS PINTO: And then from here, we
expect to be able to drive problem solutions much faster
than ever before.
You know?
So this is Concierge.
It's in the market today.
You can go to concierge.call.com.
It's available for both Android and iOS.
And we believe that it's really going
to transform the way companies connect with their customers
and employees.
And we really couldn't have built this
without the help of Firebase because we really
had a hard set of problems to tackle.
And instead of trying to reinvent the wheel,
we made a commitment to build this on a solid platform that
would scale for us at the enterprise-grade levels
that we really needed to.
So that's Concierge.
JAMES TAMPLIN: Awesome.
GUS PINTO: And take Firebase for a spin.
You will absolutely love it.
Thank you, James.
JAMES TAMPLIN: Thanks for your time, Gus.
Really appreciate it.
GUS PINTO: Absolutely.
Thank you.
[APPLAUSE]
JAMES TAMPLIN: Cool.
So we've seen how Instacart, Sky News, and Citrix
use Firebase to power some of their applications.
Now let's get to some of the really exciting bits.
We've got a couple of great announcements today.
And the first is a new feature for our real time database.
Typically, when you're building a mobile application,
it's just consuming a REST API from a server.
And in this architecture, when you
lose your internet connection, the app just stops working.
And this is a terrible user experience.
We learned earlier that the Firebase client
SDKs keep a local copy of your data in memory on your phone.
And so this allows your app to stay responsive
when you lose your connection temporarily.
But today, we're improving on that.
And we're improving on that by announcing full mobile offline
support.
[APPLAUSE]
This comes in two flavors.
The first is disk persistence.
So when you go offline, your SDKs now
not only store into memory, but they also persist to disk.
This means you can completely quit your application
and when you restart it, your data is still available.
When you come back online, it resyncs
and the entire application brings you back up
to speed and back up to the current state of the world.
Let's hop over to the [? Wolf ?] and let's
show you this in action.
So this has actually already been implemented on Talkboard.
So this time, let's play a little game of tic-tac-toe.
But all of a sudden, I lose my internet connection.
So I'm going to come in here and turn off the Wi-Fi.
And I'm going to go to the Wi-Fi.
And I'll go back to Talkboard.
So now we've lost the internet connection.
So the first thing I'll do is I'll start playing again.
And I realize the other player's isn't connected,
so I'm just going to go ahead and win the game
because they're not there.
And then I'll go ahead and quit my application entirely and say
I'm off climbing a mountain.
Meanwhile, the other player is like, what actually happened?
Where did you go?
And draws a question mark.
A while later, I spin the application back up, I go out.
Fire it up again.
Go into Talkboard.
Here's my game of tic-tac-toe.
And then I turn the Wi-Fi back on.
First of all, you've seen that I quit the application,
the data was persisted to disk, I restarted the application,
everything is still there.
Then, when I reconnect to Wi-Fi, turn it back on.
This, by the way, is the only demo of my career
that if the Wi-Fi actually drops out, it would be a good thing.
And as we regain Wi-Fi, everything syncs back
and we're up to the current state of the world.
[APPLAUSE]
We really need to focus on mobile as developers,
and features like this let you do exactly that.
We'll go back to the slides.
Another great thing is that this feature
is available with just one line of code.
This is the Android, the Objective-C, and the Swift code
that you need to enable this persistence.
Because Firebase database is built on a synchronization
approach, we've really built it-- from the beginning--
to be able to do this.
And we're excited that there's GA today.
The next peeks of full mobile offline support is Keep Synced.
Keep Synced is the ability for you
to specify data that should be prefetched
and kept up to date in case you go offline.
So a good example of this is if you're
building a social network and you
want to keep the profiles of your closest friends up to date
so that you can get at them if you're offline.
Keep Synced is the feature that would
allow you to do this and see their wall
posts from the last time you had an internet connection.
This is, again, just one line of code to implement.
Here's the Android, the Objective-C, and the Swift code
to do it again.
With both disk persistence and with Keep Synced,
if your users go through tunnels, climb a mountain,
or get on a plane, your applications
continue to work seamlessly.
And since this is just one line of code,
this continues to be a hallmark of Firebase-- our simplicity
and our ease of use.
And you can now deliver these features
that your users are coming to expect.
The second announcement we have today
is around making Firebase compatible with
an exciting new technology.
Firebase is just one piece of a complete application.
As I mentioned earlier, client side code
often needs to be structured and managed.
And that's why we've built integrations
with Angular, Ember, React.
But an exciting new technology, called React Native,
was announced a couple of months ago.
And today, we're excited to announce that Firebase
works with React Native and can be
the back end for your React Native-powered app.
React Native is an open source library from Facebook.
There's a huge community going around it.
It already has 14,000 stars on GitHub
and it's used by Facebook in their Groups product.
Firebase and React work really well with each other.
React updates your UI when there's
a change in your data model.
Firebase delivers real time updates to your data model.
The pairing is quite elegant.
You can get started by npm installing Firebase,
and then, inside your React Native code,
just require Firebase and you're off to the races.
We really can't wait to see what you build.
So you've seen our mobile offline support
and our React announcements.
We've seen what Google Cloud Platform can
do to help you be more productive, an overview
of Firebase and a feature deep dive, heard from Citrix,
and seen some announcements.
Really focusing on user experience, not infrastructure,
is going to be the way developers build apps
in the future.
Focusing on tasks, users, and data.
Firebase is enabling developers to deliver extraordinary apps,
with features that end users expect right out of the box.
With Firebase, what used to take months now takes hours.
We live in pretty exciting times.
And we're excited that individual developers
and small teams can make a massive difference.
If you build something with Firebase,
please do tell us about it.
We'd love to hear what you build.
We'll be around all day.
We have office hours at 4:00 PM.
There's some schwag over on these tables.
We're here in the yellow shirts.
Please come and find us and say hello.
And enjoy the rest of your I/O. Thank you.
[APPLAUSE]