♪ [music] ♪ My name is Mike McDonald. I'm a product manager on Firebase,
and I'm here with Jen and Abe. And we're going to build a really,
really exciting application. So I'm going to start off
with the premise of this application, and that is language is hard. So how many people--
actually, everyone put your hand up. We're going to start with this.
How many people-- and keep your hand up
if you speak one language. Excellent. Everyone speaks one language. Keep your hands up if
you speak two languages. So my hand immediately goes down. OK, three languages. - [man in audience] Does JavaScript count?
- Hah!!!! [laughter] OK. Spoken languages. So if you speak in JavaScript,
we can talk about that later. Four languages? OK. And five languages? There will be one winner--
ok, remember her. What's your name? [woman] Pavia. You will be our contestant
on The Price is Right , when we do this. OK. Moving on. Language, that's something
that I really struggle with. So I travel a lot for work. I've been to nine countries,
and as I said, I speak English. That's really, really
difficult to get around. I am constantly pointing
at things on menus or using Google Translate. I would love it if I spoke five languages
or more, like you. So technology and actually science fiction
has kind of dreamed of this for years. So how many people have read<i>
Hitchhiker's Guide to the Galaxy</i>? A couple of people? So there was the idea there
of, I think, of the babel fish. And it's a device or an animal, I guess,
that you can put in your ear. And no matter what
language someone is speaking, you can automatically
understand whatever they're saying. I would love it if that technology exists. And I've seen a couple samples of that. So I watched a demo a couple of years back of a voice-to-voice translation software where there was a bunch of kids
in a classroom in the United States speaking to a bunch of kids
somewhere in South America. And the kids in the US
were speaking English, and literally just seconds later, the kids in South America
we're hearing Spanish and vise versa. That's awesome, but that, probably,
took years and years to develop. And I would love it if maybe
it was just a device that I could put in my ear
or something, which is great. Because like a week
ago Google was like, "Hey, that's a great problem.
I wish we could solve that." And if you guys have seen the Pixel Buds,
one of the big features of that-- there are headphones,
you put them in, and you say, "Hey, I want to learn Japanese." And someone will speak in Japanese,
and it'll automatically translate it. Also awesome, but we do not have 30 minutes
to build hardware on stage. We need to do something
using a piece of technology that everyone has with them right now. Let's build an app,
because everyone loves apps. It's 2017-- apps are the new hotness. Just like the babel fish, our app
is going to let us select the language that we want to hear. And everything, at that point on, will happen in your selected language. So someone else-- it may be Abe
or one of our friends in the audience will speak something,
and all of the language will come in in that chosen language. So how do we build that? If you hadn't come to this talk, you would go home
and start immediately spinning up servers. Your mobile application
would make RESTful calls to some application server. It could be a Rails app
or a Django app or an Express app, and that's handling all
of the interesting things in your application. That is doing your authentication. That is sending things out to a database, or retrieving things from storage,
or even doing your machine learning. But that's really difficult. We have 20, 25, 30 minutes
to build this application. And if we wanted to do this,
who is going to spin up our servers? Who is going to provision them,
and manage them, and secure them? How are we authenticating people? Do we have the appropriate
performance that we need so that when we all walk out of here,
and everyone loves this application, and you share it with your friends,
and we have 100 million monthly active users, is that one server
going to handle it, right? Or are we just going to be paying
an obscene amount of money? Luckily, you all came here. And you all, hopefully at this point,
know a little bit more about Firebase. So you'll learn the secrets
of how to use Firebase to solve those problems very quickly. Firebase applications, unlike the traditional applications
on the previous slide, eliminate that application server
and let your devices talk directly to our powerful managed infrastructure. We handle really difficult problems
like client-side authentication. So if you've ever written OAuth code-- I'm assuming a few of you
have written OAuth code-- it's terrible. You don't want to do it.
With Firebase, you don't have to. We've kind of taken it up, abstracted it,
and given you a really clean interface to just do the thing
that your user cares about. And lastly, Firebase scales automatically. So when you walk out
and you all have my application, you can all share it with your friends,
and we go from 0 to N overnight. Firebase's smart clients handle
all of those really difficult pieces so you can focus on building
an app that your users love. OK, so in case you weren't
paying attention during the keynote or somehow stumbled into this conference
and have no idea what Firebase is, the brief slide-- Firebase, again, is
Google's mobile platform. It helps you develop your apps
on top of Google Cloud Platform, engage with your user base,
and really understand what they're doing. It's a one-stop-shop
for mobile application development. But there are a lot of products
on this slide, and we have a very short time. I'm going to invite Abe up here
to talk about a few of these products and how they help make
our app more successful. Thanks, Mike. [applause] I'll be honest. That's a lot of orange circles. That's probably too many
for us to explain right now and, probably, too many for you to dive in
and really understand in depth. And that's OK, because
you don't need to. From the beginning,
a core tenant of Firebase was that you would not
have to use every part of it. Today if we're building an app
that needs some specific functionality, we can pick and choose
out of this array of features. You don't have to pull in the whole SDK. You don't have to use every feature. And if you have some other solution
for part of this that you like, that you want to keep using, you can do that and use Firebase
for the rest of your application. Today, we're only going
to be using three features-- that's Cloud Storage,
Firebase Authentication, and Cloud Firestore. Cloud Storage is important because
we're going to be dealing with files. We're going to be uploading audio
from devices to translate. Authentication is important because
we're going to be doing that securely. We can't have people just
throwing files at our server and willy-nilly writing
over other people's data. And lastly, Cloud Firestore is important
because we need real-time synchronization. As soon as our translations are done, we need everyone to hear them
as quickly as possible. So we'll hand that off to Cloud Firestore. Let's dive in
a little more in detail, though. Cloud Storage for Firebase is
an amazing way to upload files. It is honestly amazing. If you've ever dealt
with files as a concept, if you're saying I want
a profile picture for my user and I want to upload that,
that seems simple. It seems trivial. It's trivial to describe but to implement
there are a million concerns. What if they don't upload a JPEG?
What if they upload an MP3? How do I handle that?
How do I know what they're uploading? What if they uploaded
an 800 megabyte ISO instead of an image? Can I stop that? What if I run out of storage space
on my hard drive? What is my persistent storage? All of these things are concerns, and that's not even to mention things
like network flakiness, network latency, and the scalability
once you get the file to your server. This is literally an issue
that you could spend weeks messing with. But with Firebase, we make it simple. Cloud Storage lets you take a device, talk directly
to our scalable infrastructure, and upload files securely, quickly,
and in a way that is extra resilient. You're not just making an HTTP request
and throwing a file at it. We'll do recovery, and we'll make sure
that the file gets up there accurately in a safe, quick way. Once it's up there, though,
the second half of the story is, of course, serving that file. In Cloud Storage, it'll be sent down
to as many devices as you want. If that's four devices, that's great. If it's 4,000, that's great too. You can just get a URL,
a normal download URL. You can embed it in a page.
You can get a stream of bytes. Any way you want to consume
that file out of Cloud Storage, you'll be able to do. And of course, if you want
to restrict access and say, "Oh, only this person
can upload documents to their own folder, only them can read it." That's all right, because
we have Firebase Authentication securing this whole thing. Firebase Authentication
is, like Mike said, a wrapper around
traditional OAuth technologies along with some extra Firebase magic. OAuth is a huge pain. And one of the reasons it's a huge pain
is because it's different every time. It might be a standard,
but there is nothing standard about it. Every implementation
is just a little different. So if you wanted to live in a world
where you had Google login and you had Twitter login
and GitHub and email password, you would spend weeks going through and figuring out
how to deal with the handshakes and the extra effort required
to implement each of these providers. But in Firebase, not only
do we make it easy to set this up, but in your code, regardless
of how someone authenticated, that user looks the same to you. You get back a Firebase user object. It has the same fields, has the same data, and works with your security rules
and other services in the exact same way. We'll see this later on. We're going to build an app
that has multiple <i>Sign in</i> options on multiple native platforms,
and they're going to sign in and access the same resources
without any extra effort from us. Because once they're signed in,
it's always that same unique ID. It's always secured to that specific user, and you just don't have to worry about it. The last part-- once we've
uploaded that file securely, once we've dealt with it,
somehow translated it, maybe using some sort of magic--
we need to sync that back down. Now, you might have heard today
for the first time about Cloud Firestore, our brand new NoSQL database. And the truth is,
it wasn't announced today. It came out about a month ago,
and we've had EAPs for a long time. And we really, really think
this is an amazing way to deal with extremely scalable applications
that require a ton of querying, but still want speed
and all the other coolness that you expect from a Firebase product. In this case, Cloud Firestore
is a little different than what you might have seen in the past. We use a document and collection model. If you're not familiar
with those NoSQL jargon, then you can go ahead
and think of collections as lists and documents as just objects of data. In this case, we're going
to have three top-level collections. That's uploads. When we upload a file,
we'll write to the uploads collection to actually kick-off
the process to translate it. We'll have transcriptions,
which is the transcribed version. In other words, if I say hello,
we will have a string 'hello' in there. And then we will have translations, and that is what will actually get
passed back to our application. So we'll take the transcription,
run it through some magic, and get back a whole
bunch of different languages. So, hopefully, everyone in the world
can communicate and do so peacefully. And of course,
this is all done in real-time. Connecting those different collections, synchronizing it back down to the client is all done with the real-time
aspects of Cloud Firestore. We're not polling--
we're not waiting for something to happen. We don't have to do
an exponential backoff in case it took too long
or anything silly like that. We just know the clients who want
that translation are going to get it as soon as it's available--
so we don't have to worry. But of course, this is all abstract.
We're talking about products, and I'm telling you random things
that we can do. But that's not very interesting. We are mostly all engineers,
so let's write some darn code. And of course, because we are not
all Android engineers, and we are not all iOS engineers,
it's not fun to do one or the other. So we're going to do both
at the exact same time, which is extremely difficult. So we will see how it goes. The very first thing you need to do, once you've set up your Firebase project,
imported the SDK, and initialized Firebase in your app, is just access the services
you want to use. In this case, that's those
three services we talked about-- Cloud Storage, Cloud Firestore,
and Authentication. Once we've done that,
we can just jump straight to it. Let's upload a file. To do that we need to get
a storage reference that points to a specific
location in Cloud Firestore. Think of it as a folder--
it functionally is. And then we can go
and actually, upload to that location. We'll tack on some metadata--
you know, what is a file type. But that's all extra and optional. We're doing it here because
we get different types of audio from different devices. Once we get to actually uploading the file,
there's one method-- <i>PUT</i> file. And that's the really
magical part about this. When you put that file,
a million things happen, a million things in a million languages
in a million places. But all you care about is,
Does it get uploaded? And, Can I access it? And to know that it's all uploaded
and all complete, we get back a completion listener
we can tack on. This completion listener will just tell us,
"Hey, was there some issue?" Have I been without internet
for a long time? I couldn't upload it. Or did it go completely successfully
and get uploaded to Cloud Storage? When it is uploaded successfully,
we're going to go and I'm going to write in Cloud Firestore
to that uploads collection. That collection is what will
trigger off our processing and allow us to actually
translate our message. So if we ran this right now,
would it work? No, it wouldn't work.
And there's one big reason. And that's what I've been talking
about this whole time, which is right now
we're not authenticated. We're not any user in our application. We're just some person
who happened to connect, happened to have the right API key, and pointed it out of Firebase service. We're not securing this at all,
and that's extremely dangerous. So by default,
Firebase locks this down. And we say, you have to be
authenticated somehow. You have to have
Firebase Authentication set up. So we're going to go ahead
and set up Firebase UI. Firebase UI is a brand-- not brand new. It's quite old, but an amazing
open-source library that is a headful version
of Firebase Authentication. Firebase Authentication gives you
all the methods you need to do all the authentication, but it doesn't actually
show anything onscreen. It's up to you to wire it up. So Firebase UI gives you
that really pretty screen that says, "Pick your provider,
what do you want to log in with? Choose whatever you want." And that's all we need to do
to actually do authentication. Cloud Storage and Cloud Firestore
are now aware of that Authentication state, and we can start accessing these resources. And of course, you can go and set up
whatever security rules you want. You can configure it: different people
can write to different locations. In this case, we're just checking
that you're authenticated before letting you upload. Now that we've done that,
the last thing we really need to do is listen to that translations collection. That collection is where
our final translations are going to come out of. So we're going to create a reference
to that collection just like we did before. But now we're going
to do something different. We're going to use an onSnapshot listener. And this listener is our way of saying,
give me real-time updates. It's a little different than if you've ever
used real-time databases, like Firebase Realtime Database,
or any of the other ones. But the general idea is the same. We'll order it by a timestamp
so we always get the most recent translation. And we'll check to make sure
the document exists when it comes in, look at what the event is. But then most importantly,
we'll call out to a native API using the language
you selected in the UI, and we'll say, "Hey, speak this out." So, if you write to that collection,
if any translations come in, both of our apps will speak it out. And that's basically it. We've written all the client side code
in order to make a translation app, right now, for two different platforms. And that's absolutely crazy. So let's give this a shot. We're actually going to try it, using one of the greatest
machine-learning APIs known to man-- Mr. Mike McDonald. He going to go into our Firebase console
and give this a shot. So he'll-- yeah, once he logs in, because, of course, it's secure. So he has to type his whole password
and everything like that. And you'll notice
that the really cool thing about this is that we added two lines of code, but he's getting a full native
Google log in experience-- all the things about saving your password
and all the niceties you expect with Google Authentication in general
are brought in with Firebase UI. So here we can see
this is a simple object. It has a unique ID,
then a language as object, and that just has a translation. In this case, we're only translating
to English and Spanish because those are the only languages
the three speakers know. But with any luck,
if you select English on your app and you send this in,
this will speak out to us. So let's give this a shot. We'll write this to the database, and we'll see if it makes
it down to the application. [computer] The food is delicious. [Abe] There you go.
That was very fast. So that might have been very, very fast. And you might be thinking,
"Well, you're on stage, we faked that." That's how fast it was. That was Firestore Realtime syncing
back in the US to here, extremely, extremely quickly. So that works. But Mike McDonald,
although he's a great translator from English to English,
he doesn't scale to other languages. And if you tell him to translate
more than five things, he gets grumpy. So we're going to come up
with a better way to translate things. And I'm going to pass it over
to Jen to talk about what we can do to really make this
into a great translation app. Jen? [applause] Thanks, Abe. Can we go back to the slides? Thank you. So as Abe said, we're not quite done here. Because as great as Mike
is at translating, that really doesn't scale very far
past just the three of us. So we're going to write some software
to fill in that gap, using the trendiest way possible-- by adding some machine learning. But designing and training
our own modules from scratch takes a lot of time,
and that's not what this talk is about. We just built an app really fast,
and we wanted to get it working fast. So luckily, there are
some pre-trained machine learning APIs. And we can pick from a big menu of APIs that are part
of the Google Cloud Platform. They solve a lot of common problems
that developers have. And in this case, the two
that we're going to be using are, for transcribing, we use
the Cloud Speech API, and for translation, we use
the Cloud Translation API. So there you go-- problem solved, right? Well, almost. How are we going to wire
these really cool APIs up to our serverless app? Traditionally, with Firebase, apps
would bake everything into the client. And that's really great,
because it's serverless. And as you saw, we covered a lot of ground
in a short period of time. But we've run into
a few challenges with this model, and these are challenges
faced by a lot of apps as they start to grow
and get more complex. For instance, secrets. So users can learn a lot from the files
that make up your app. So pretty much anything you put in there,
the users may be able to find it, such as pre-release game code
or API keys, such as the ones we would be using
for our cool APIs that I mentioned. Also, we have to worry about resources. Phones get faster all the time,
but the battery only has enough oomph to crunch so many numbers
or, in this case, so many phrases. Finally, there's just the idea
that it's a real pain to have to write
the same functionality over in all versions of your app
for each platform. It would be much more convenient
if you could have that all in one place. Now, our app is pretty simple, but it still has all three
of these challenges. And they can be mitigated
by moving our secrets and resource intensive code
into the cloud. And since it's in the cloud,
we'll only have to write one version of it, thus solving our third problem. If we dip into our old bag of tricks,
we might solve it this way. We might spin up some servers
on the compute engine, create APIs backed by Django or Node.js, but we know there's more complexity that the meets the eye
in this little, cute compute icon. If we do it like this,
we'll still have to worry about caches, microservices, and load balancers. And if you're very familiar with Firebase, you probably know
where I'm going with this. Before we know it, we're back here--
lots of complexity, which we're trying to get
this going really quickly so that Mike can go travel
around the world speaking other languages. So of course, we'll use Cloud Functions. That gives us the minimal glue
that we need to run our serverless app and solve these challenges. And of course, Cloud Functions works
across many different Firebase features. But in this case, we're going
to be focusing on using it for Cloud Firestore. But why show you
some more silly diagrams when we could show you
some really cool live coding? So Abe is going to show us
what it's like to build these Cloud Functions
that we're going to use in our app. So we'll start by attaching
two functions to Cloud Firestore. One is going to listen to any documents
added to the uploads collection, and the other is going
to listen for documents added to the transcripts collection. So first, we'll import
the Cloud and Firebase APIs and initialize the Admin SDK to use. Then when this initial function
is triggered, when we upload the metadata,
it's going to be extracted using the language, encoding,
and sample rate to use the transcription. So here you'll see,
we'll run <i>speech.recognize</i> to get the transcription. Then we'll write that transcription
back into Firestore to a new document
in the transcripts collection. This document, of course,
will trigger our next function to run. And again, what we're going to do
is take that transcription and translate across
all these various different languages. Once they have all been translated, we write that result back to Firestore. And this is the part
that our app is listening to. So once it sees that something else
is written to that area in Firestore, it's going to readout
that new latest translation for us. All right, looks great. Thanks. Can we go back to the slides? Thank you. So there's still one more step
with these Cloud Functions. We need to deploy. And we're very brave to do some live coding
and play it for you, but a live deploy
can take quite some time. And again, we want to get
this app going quickly. So through the use of video magic, we're going to deploy our app. And I'm going to hand it back to Mike
to show you how this works. [Mike] Thanks, Jen. [applause] So if you're paying
really careful attention to the slide, you'll notice that,
in addition to the functions, we also deployed something else. So for the grand unveiling, if everyone would like to go
to <i>babelfire.cloud</i> on their mobile devices, bring that up and select your favorite language. Give people a minute. You should start hearing
some words in other languages very soon. I feel like we could have had a QR code. I think I heard someone. Yeah? People have it up? Jen, do you want to say something
into your app and see if you can get-- there you go. [Abe] We're working
in English and Spanish, the languages we put in. [Mike] Let's add another one. [Jen] Real data, right?
OK. Let's see. I remember my sixth grade Spanish here. [Spanish] <i>¿Donde esta la biblioteca?</i> [Jen] Hopefully this is only for-- input and not also output,
because if we're using this for-- - [Mike] We're getting that phrase a lot.
- [Jen] The food is very delicious. [Mike] It is very delicious. Oh. I just heard <i>biblioteca</i> somewhere. - [computer] Where is the library?
- [Mike] OK, there you go. Can we get our member of the audience
who speaks multiple languages to come up and try this in a language-- well, we did Spanish. Do you speak one
of the languages on this list? Do you mind coming up and-- everyone welcome her to the stage. [applause] Do you mind standing over
with Jen and utilizing that app? So, everyone, select the language
that you want to hear. We promise it'll work this time. [Jen] So you hit record,
and when you're done, click stop. [Pavia in Hindi] <i>Mera naam Firebase hai.</i> OK. Wait in anticipation. [Abe] We forgot to say
it had to be work appropriate. [somebody speaks from the audience] [Mike] There you go. Oh, is it set to English? Well, it's going to be English
on my screen, but it still translates in all the-- [Mike] Set it to Hindi. [Pavia in Hindi] <i>Mera naam Firebase hai.</i> [computer speaking Hindi] [Mike] There you go. [Abe] The crowd of translations. [Mike] Awesome. Thank you very much. [applause] So there we go. Between the three of us, in--
how long was that? That was just under half an hour.
- [Abe] 4.5 minutes. Just under half an hour, we built two entire applications
complete with a backend that did translation from any
of about 8 or 10 languages. Before today, you may have gone home
and spun up a server and written your own
machine-learning algorithms, and you'd be taking a lot of time. People like us might beat you to market. You'd be paying a lot of money
to maintain those servers, and you're spending a whole lot more time
dealing with server issues rather than building features. Abe came onto the stage
and showed us a really cool way of getting rid of all of that,
replacing it with Firebase and doing exactly
what your end users care about: uploading those audio files, synchronizing data in real-time,
securing all that information. And then Jen came and showed us
how to leverage Cloud Functions to glue all of those pieces together. She took Cloud Functions
and connected Cloud Firestore to the speech and translate APIs. And just as easy as it was
to wire up those two, there are a ton of other services
within Google Cloud Platform that you can take Firebase
and Cloud Functions and stitch together, more pre-trained ML services. just general other--
there's a Jobs API if you ever want to look for a job,
you can do that on Cloud Platform as well. And it's just as easy
to trigger those events and chain functions together
as it was in this talk. It turns really complex processes
into step-by-step workflows that scale as you need them. So thank you all very much for coming. Hopefully, you've learned
a lot from this talk. Feel free to reach out to us on Twitter, or we will all be
in the Ask Firebase Lounge right after this. Thank you all very much and enjoy
the rest of the conference. [applause] ♪ [music] ♪
