Zero to App: Live coding a Firebase app in JavaScript, Kotlin, and Swift (Google I/O '17)

[MUSIC PLAYING] MIKE MCDONALD: Good morning, everyone and welcome to the second day of Google I/O. Hopefully you’ve met a lot of really great people, learned about the coolest new technology, and seen some great product launches But there there’s one launch that you haven’t seen And I am so confident in this launch that onstage at Google I/O I’m announcing that I’m leaving Google to start a startup to build this app And in short, this idea, it’s so revolutionary, I want you, all of you, to share your story with your friends, with your family, with everyone on the internet You deserve to share your story Nobody has done this before, absolutely nobody So I’m confident that will be the first to market And I’m so confident in fact, that I have already called all of my VC friends and we have meetings scheduled an hour from now But I think I was a little too confident We actually don’t have anything yet So I have this great idea but in order to get funding I need to show that it’s a viable concept I need an Android app, an iOS app, and a web app to actually prove that we can get users So I have a bunch of really smart people at Google and they all told me build an app that looks like this So have an application, your web app, your mobile app that talks to some database server And that database server proxies all of those app requests out to these storage systems, databases, and APIs That server is going to have all of my authentication logic, all of my business logic It will control who can read and write the stories and where those stories get sent But that sounds like just a ton of work, and I scheduled meetings for like 45 minutes from now So I can’t build this alone I’ve asked a couple of my friends to come out and help, Jenny, Frank, and Kat, can you guys help me? FRANK VAN PUFFELEN: Love it We all have a friend like that, right, who comes up with this great app idea and then sort of gives you 30 minutes to build it because how hard is it to build an app, especially here live on stage So it’s a tricky, tricky situation We have to build three applications And we have, what did he say? 30 minutes So let’s not do this architecture What we’re going to be doing today is we’re going to be using Firebase to build these applications And that means that the application code talks directly to our powerful managed back end services This means that Firebase takes care of all the things like scalability and security so that we can focus on building the features that our users love It takes a bit of time to set everything up so while the team is prepping on their laptops I’m actually going to talk a bit about how we’re using Firebase and building this application So remember, we are building a story sharing app So we’re taking a picture on our phone or selecting a picture on a laptop and then we’re sharing it with the other users with the app First thing we need to do is we actually need to allow the users to sign in And we’re using Firebase authentication for that Second thing is that we need a place where we can store and share the photos So for that we’re going to be using cloud storage And finally, we need a way to store and synchronize metadata between the users And that’s the Firebase database We’re going to go through each of these features in turn I’m going to explain how we use it in the app and then we’re going to switch over to the code and see how it works in practice So you’re going to be experiencing firsthand how easy it is to build an app with Firebase First up, Firebase authentication It’s our secure serverless sign in solution And we’ve taken all the complexity of storing email addresses and passwords, server side overflows, and we’ve wrapped them in a single cross-platform client side API That means that your users can sign in with Google, Facebook, Twitter, GitHub, or email passwords And if you watched any of the session so far about Firebase you know that we now also support phone number authentication And that’s great because that means that even if your users don’t have an account they can just sign in from their phone, get a verification text message, and continue using the application To speed things up a bit today we’re going to be using Firebase UI, which is our open source library for authentication So it handles all of the complex flows that you might have like is this a new user or returning user, do they want to sign in with Facebook or Google? And for example, password resets, email verification, account linking

Actually, it handles a lot It’s an open source library built by the identity experts at Google And it includes years of experience and best practices for sign in flows I think that’s pretty much what we need to know Can we switch to the split screen to do some coding? So to speed things up we’re going to be building all three applications at the same time Top left you see Mike’s screen And Mike is building the iOS version of our FireStories app At the bottom left, you see Kat’s screen And Kat is working on the web version And at the top right, you see Jenny’s screen But hold on, Jenny, that doesn’t look like Java code that I’m used to JENNY: No FRANK VAN PUFFELEN: Did you switch over to Kotlin last night? JEN TONG: Yes I switched it last night FRANK VAN PUFFELEN: Actually, that’s going to be great because it’s going to be so much less code that you need to write for this So they’ve all already built the basic framework for the application So they’ve added the layouts that they need to show the stories and added the inputs where the user can select or take a picture and to put them where they can send it So if we now run the app we can access the device’s camera or the local file browser and we can take or select a picture But if we hit send, nothing happens That’s because we’re not using Firebase yet So in the bottom right, you see the Firebase console This is where you manage all of your Firebase projects We’ve already created a project that will serve as the back end for this application Now all these applications, whether it’s iOS, web, or Android are talking against the same back end services So they share the same list of users, the same file storage, and the same database And that’s great because that means that they’re sharing all their states We’ve taken the configuration data of this project and added it to each of the platforms So now the apps can find their back end services on the Google servers We’ve also already added the SDK to each of the apps So we’ve done a pod install, a Gradle dependency, and we added the script includes So with that, I think we’re ready to start coding First thing we need to do is we take the features that we’re using about Firebase and import them from the SDK into our code We do this in one go for all three features that we’re using, off, storage, and database You can see that the code looks exactly the same for every feature So we have a cross-feature consistency with Firebase That’s great because it allows you to start using new features quickly But if you actually glance from screen to screen you see that it is really also very similar between platforms And that is great because it means that you learn Firebase on one platform, then when you switch to another platform you take what you’ve learned and use it on the new platform also I think we’re now wiring up Firebase authentication So let’s get to that one First thing we need to do there is that we need to configure Firebase UI for the providers that we want to use So today we’re only using Google sign in because we only have a few minutes left We also, in the Firebase console, enable this provider Next, we’re going to wait until the user clicks the Sign in button, and when they do, we start to sign in flow Now this is a very short amount of code but it triggers all the complex flows that you can imagine So if the user signs in on an iOS device tomorrow but on an Android device the day after they still have the same stories And when they want to sign in with Facebook today but with Google tomorrow it handles account linking for you All of that behind this simple code What we need to do is listen for when the authentication state changes And when it does it’s either one of two things Either the authentication succeeds or the user did not sign in If the user signed in we hide the Sign in button, show the Sign out button, and we enable any other UI elements that require an authenticated user That’s really all we need to do So if we now run the application we have Sign in working Let’s see who gets there first I think Kat is already signing in You can see that we get pop ups, we get to pick our accounts If we have multiple Google accounts we get an account picker All of that is handled for us with the minimal code that you just saw But just signing in on an app is not very interesting So let’s switch back to slides and see how we’re going to be using cloud storage If you’ve ever used Google Cloud Storage before you know that it’s our petabyte-scale storage

solution Firebase provides a cross-platform client site SDK on top of cloud storage that allows you to upload files securely directly from your device We provide the security model on top of this so that you can ensure only authorized users have access to those files from their device But whenever you upload a new file through Firebase you also get a download URL This is an unguessable URL that provides read only access to that same file That is great for our FireStories app today because we can use that to share the image between all our users I actually think there’s nothing more we need to know about cloud storage So let’s switch back to the code and see how we make this work We’re back in the code Remember, we already imported the feature before So what do we now do is we have a local file that the user took with a camera or selected from the file browser First thing we need to do is we need to figure out where we are going to store that file in cloud storage And it’s going to consist of two pieces So the first piece is the user’s UID So this is the identification of the authenticated user And by putting this in the path we actually make sure that the files from the various users end up in different locations That is great because that means that we can use Firebase’s server side security rules to ensure that only the authorized user has access to their files So that if Mike uploads a new story only he can change that picture The second part of the path is really just a unique filename because since we are writing to the same cloud storage location we want to make sure that we don’t override files we uploaded previously Next step is that we start uploading the local file to that storage location So we take the storage reference that we just created and we tell Firebase to put the file to that location This is all we need to do to start the upload in the background Now think of all the things we did not have to do here We did not spin up any threads There were no async adapters, no background tasks, no Grand Central dispatch All we did was tell Firebase to start uploading the file and it went to work All we have to do is wait for the upload to complete And when it does, one of two things can have happened Either the upload succeeded or it failed If it failed, we take the error message that we got from Firebase and we show it to the user And if the upload succeeded, we take the download URL of the file that was just uploaded and we display that on the local screen That is all we need So if we now run this app we’ll be able to upload files to cloud storage I see Kat is already selecting an image We don’t really see a lot yet If in the console we switch to the Storage tab in the Firebase console on the bottom right Kat, can you switch in the console? Can we go back to the split screen Thank you So, we have files here now These files were just uploaded but not a really impressive way of uploading a file But it is a very cute dog in there So clearly, we can now upload files to the cloud Not really what we wanted yet Nothing we can go to our VCs with So we’re going to be using the third Firebase feature to actually share the information between our users Let’s switch back to the presentation The Firebase database is our oldest feature And it’s still one of our most popular back end services We have hundreds of thousands of applications that rely on our database every day The Firebase database is a cloud hosted NoSQL database It’s really just a JSON tree And if you’ve ever modeled your data with JSON you know that it’s very flexible So this is the data model that we’re using today At the top level, you see that we have a node called stories And under that we have a child node for each individual story Then for each of those stories we keep the download URL Remember, that’s the unguessable but publicly readable URL And we keep the title that the user entered for that story We also keep the user ID of the user who created the story And just like before with storage, having to UID in the database allows us to secure access to the story with Firebase’s server side security rules So that is great because it means that when Kat enters a story only she can change the title of that story We call our database a real time database

And we do that because of the way you read your data from it So with most databases you do something like SELECT star FROM stories And then you’d get the list of stories back and you display it on the screen With Firebase, you attach a listener or an observer to the story’s node And from that moment on, Firebase will tell you whenever something changes under the stories node So when Jen uploads a new story, Kat and Mike get informed of that instantly And when Jen responds to that story, Mike gets the update straight away This is real time synchronization And it’s really, really easy In fact, let’s not take my word for it Let’s switch back to the code and the final feature to the app So let’s see, we already imported the database So we’re going to go back to where we upload the file and we added it to the local screen So first, we’re going to remove that code We’re not going to play the story any more because we are going to instead write the metadata of the story to the database So to do that we create a reference to the stories node in the database Since we point to that same node in each of the apps they’re going to be writing to the same location in the same database And that makes data sharing really easy But since they’re writing to the same location we also need to make sure we have a unique ID for the story that we’re creating So we’re coding push or child by auto ID for that With that, we’re ready to write the metadata So we take the reference that we just created and we write the values of our story to it So we write the download URL that everyone can display We write the text that the user entered We rewrite their UID so that we can secure access to the story And finally, we also writes the path in cloud storage because I think that might come in handy at some point but I’m not sure where yet I just have a feeling Now we can run the app again And if we do, and we pick a story, it we will write that data to the database If you look at the bottom right, you see that we’ve opened a database panel in the Firebase console And now we’re going to wait for the stories to pour in I see that Mike is already selecting an image Kat is working And you can see that the database lights up as the new stories come in That is great but it’s just one problem left Ooh, smile, you’re on camera There’s one problem left It doesn’t show on the local screens anymore So that’s the final step we need to take in our code We’re almost done here, folks So we’re going to attach a listener to the same nodes that we had before, to the stories node And we’re going to ask Firebase for the last 10 stories Now from that moment on, whenever a news story is added Firebase will fire the child added event And with that event we get a snapshot of the story So we take the value out of that snapshot That’s the value that we just wrote and we display it on the local screen again by calling display story That’s it This handles most situations We’re going to do one extra one because I’ve been telling about changing the story securely so much that I want to make sure that works too So in addition to handling child added we’re also going to listen for changes to the stories, which works with a child change event So now whenever somebody changes a story we get a snapshot of the updated story We take the value and the key of that story and we update to display on the local screen I think we’re ready to run So now you can see that if we run the app, stories that we just created actually are already showing on each local screen So that child added event that we were talking about fires immediately for any existing children But now as they’re taking more pictures and writing more stories those stories show up on all screens within milliseconds This is how you build a multi-user story sharing application with Firebase In fact, I’m not sure I didn’t read the full spec of the requirements but I think we’re pretty much done here, Mike And it took what? Like 15 minutes I think we have like 40 minutes left to actually go play in the ball pit What was it? MIKE MCDONALD: I hope they like it FRANK VAN PUFFELEN: What’s wrong, Jen? What’s wrong? JEN TONG: Wait a second, Frank I’m just getting a call It’s our VC Our VC says that there’s already a bunch of apps

that do basically this thing FRANK VAN PUFFELEN: No way JEN TONG: But you want what? Oh, my gosh Frank, we need to pivot like now Good thing we have like 20 minutes left So it turns out, if you go back to the slides, it turns out that there are a lot of apps out already that do real time communication, that do chat and pictures and text and stuff And it turns out, that’s so a few years ago and people are interested in new stuff now Specifically, people are tired of reading text and looking at their pictures Instead, they want to look at their pictures and look at other tiny pictures next to their big pictures So we need to a emojify our app today But it’s OK Pivots are hard but we’ve been thinking ahead Our skunkworks engineering team has already thought of this and already developed a really cool emojification algorithm that will take us to the next round of funding But, like any big engineering change, we have a few challenges that we’re facing You know, we’re pivoting For example, we have somehow burned through a lot of our engineering resources already I think it might have something to do with the bouncy castle in the break room Anyway, we don’t have time to write it for all three platforms anymore We have to take our original emojification algorithm and write it once so we don’t have to port it to all the different platforms Another problem we have is our emojification algorithm is super great and target’s really well but it consumes a lot of resources And although mobile devices are faster than ever before their battery life has been kind of flat over the last few years And we need to make sure that we save our users batteries so they can be taking tiny pictures of their big pictures all day And finally, security So we have our proprietary emojification algorithm but as you build out an application you end up with secrets that are part of your app, whether they be API keys or other stuff like that And if you put them into your app and deploy them to the world some of your beloved but possibly nefarious users are going to find that information and might do bad things with it And we don’t want our emojification algorithm to leak out because that would ruin us But it’s even more OK because the same skunkworks engineering team that developed the emojification algorithm has also come up with a solution to the problem Turns out, Cloud Functions are the solution to the problem So Cloud Functions allow us to take our already written JavaScript emojification algorithm that we developed on Node.js and port it over and deploy it to the cloud where it solves all of our problems First of all we all have to write it once and then we can hook it up to all of our apps because Cloud Functions integrate wonderfully with the rest of the Firebase SDK And it also allows us to run on Google servers in the cloud, which as it turns out, are plugged into mains electricity And since it’s deployed to the cloud we don’t have to worry about people extracting information from our deployed apps So we have a solution, we have a plan, and we have some JavaScript The first thing to do to appease the VCs is of course to update the architecture slide, since this is how they think This is where we left off before We have our application on one side This is all the different applications for all the platforms that are using the Firebase SDK to communicate with the database and storage And this is how stuff gets synchronized between them So were going to shift the apps up a little bit and we’re in a plop Cloud Functions right here Cloud Functions, when integrating a Firebase, kind of acts like another client It’s like a super client that’s there all the time and it can always watch for changes that happen, make all those heavy lifting operations, and then push them back to Firebase to the database into storage, where the clients will automatically get notified, just like as if another client did the update So I could talk about this all day but why don’t I just show you some code Sound good? Switch back to the code So here we are And we have down in the lower corner, Kat is our JavaScript whiz and she has been the one who developed the emojification algorithm so she will take the helm today And as you can see, she started out with a few imports, like our emojification algorithm, but she’s ready to get coding So the first thing you’re going to do is you’re going to write out a function header This is where you actually wired up to the Firebase database Here you can see that it has a path to Firebase and it is listening for writes on that location Because we’re integrating with an already existing app, this listens to the same location where our stories appear today

It’s going to behave just like an app so we’re going to have a snapshot handy So the next thing we’re going to do is we’re going to unpack the title with boring old text from the snapshot Then we’re going to do the magic We’re going to take that title and we’re going to pass it off to our emojification algorithm, which will take the title in and a wonderful stream of emoji will come out Finally, we’re going to take that emojified title and we’re going to stash it back in to the database in a new field in each story that gets updated But we have to do one more thing before we can deploy it The behavior for triggering on functions is a little bit different than on the clients It’ll actually trigger for each write instead of on a slightly more specific child added event So we’re going to add a short circuit up to the top to make sure that we don’t actually accidentally re-emojify something that’s already been processed And with that, we’re ready to deploy So we’re going to go on, deploy that code up to the cloud And here’s the really cool part Our applications were already aware of this field when they displayed the stories So we don’t have to deploy the app So you don’t have to recompile the Android app We can just run it and all the new titles that get added are automatically going to get emojified And people can be super happy looking at all those little tiny pictures And that’s great because we’re saved now, right? We have our emoji in our app and we can buy that kombucha on tap KAT FANG: Hold on JEN TONG: Wait, what? KAT FANG: My friend, Dog, is calling And my friend Dog says we’ve been mislabeling dogs People are really bad at identifying dogs and call them sheep– JEN TONG: Oh, my god KAT FANG: –and bananas And what’s that? You’re afraid people will upload bad photos JEN TONG: Who would do bad things on the internet? KAT FANG: Oh, cat photos Yeah, you can see the temptation All right Well, it looks like we have some more work cut out for us So let’s go back to the slides because I’ve got an idea We’ll be able to use machine learning We will be able to fix this problem And I bet we’ll be able to get the VCs on board if we can say we’re using machine learning How can we use it? Well, we’ll still have people upload their photos, same as before But instead of making them type in the title we’ll just figure out what’s in the image and perform our imagification on that And while we’re there, people seem to really enjoy not having to read In fact, I’m not really sure my friend Dog can read at all In fact I’m not sure my friend Dog can type So getting rid of the title is probably a great move We can also get rid of the complicated images Just get rid of those and keep the super simple beautiful emoji So our app will look something like this Just a giant stream of emoji It’ll be fantastic But we spent all of our time engineering on the emojification algorithm and we haven’t spent any time on machine learning Good thing we’re at Google I/O. And cloud has some APIs that can help us with this So let’s just put a cloud on it Every Firebase project is also a cloud project That means we can use the same project to access the cloud APIs and the cloud SDKs In this case, let’s make use of the Vision API, which will allow us to look at an image, determine what’s in that, and based on that, we’ll be able to go ahead and perform our emojification algorithm and spit out a stream of emoji So where does this fit in our architecture diagram? Here’s where Jen left us off We have Cloud Functions now, which act as a special client that can listen to Firebase Now we just need a little bit of room to fit in one more new icon So we’ll just shift everything over and, bam, we have room for our Cloud Vision API We’ll create a new cloud function, which runs in a secure environment So we can put in our project formation so we can talk directly to the Cloud Vision API, do that intense computation, and write it using the Cloud Function back to the database So let’s code one last time The first thing we’re going to want to do here is actually hook up to the Vision API And once again, you’ll want to be focusing here in the bottom left We’re using here our Firebase project credentials, the same ID And we’re going to make use of the Cloud SDK, the Cloud Storage SDK as well So now that we’ve hooked up our API we’re going to go ahead and define a new function It’s listening to the same place in the database because we want to pick up those same images

We’re still listening on right so we can fire off multiple functions from the same place But instead of grabbing the title, which we no longer have, we’re going to want to grab the image using the file path that Frank so kindly snuck in for us earlier Once we have the file path, we’ll be able to use the storage SDK to grab a reference to that file And with this new reference we’ll be able to go ahead and pass that to the Vision API to detect labels and find out what is in our image Once we have the labels, the response from the Vision API, we want to filter over just the labels and then we can emojify those labels Once we have our emoji, the last thing we need to do is write it back to our database Here, instead of writing to the same location we’re going to write to a new location, emojis This allows us to differentiate between who can write and view stories versus who can look at the emojis And honestly, everyone deserves emojis so we’re going to open this up to the world So we’ll deploy our new function And any new images will now get emojifiied and labeled automatically We’ll update the clients so that they now listen to the emojis field instead of the stories field And we’ll start getting a stream of emoji, a nice, definitely comprehensible stream of emoji So what do you think, Mike? You think we’re going to be able to get that funding we need? MIKE MCDONALD: I don’t know, Kat I say let’s let our first couple of users take a crack at it and see what they think In the meantime, we’ll do a quick recap Could we switch back to sides, please At the beginning of the talk, I presented this problem How do we build an app in under an hour that we can present to our investors? And Frank came on stage and showed us the easiest way to do that, to use Firebase, Google’s mobile platform to build your application for Android, iOS, and the web He used Firebase authentication to securely sign in our users, cloud storage to upload and share those files, and the real time database to synchronize file metadata across all of our clients Firebase lets you build your app incredibly quickly without having to worry about managing servers or infrastructure, writing your own authentication or authorization code, or dealing with database synchronization Then Jen and Kat showed us how to extend our app’s functionality using Cloud Functions and the Cloud Vision API These features supercharged our application and let us protect our proprietary emojification algorithms, which even though all of you have seen, they’re still secret Trust me And enhanced those algorithms using the power of machine learning And unfortunately, since you all don’t work with Kat, Jenny, and Frank, we’ve provided a number of other tools in Firebase to provide that level of support when you have to go and build your application and pitch to your investors Firebase offers high quality developer documentation in a number of languages, developer tools integrated with Android Studio and your other favorite IDEs, and high quality, free technical support If you’re interested in diving deeper into any of these concepts with Firebase there are a number of other talks available today and tomorrow over on stage seven in the main area And all of us and our team members will be available in sandbox H if you have any additional questions So let’s check in on those users again Let me give them a call Hey, what did you think of the app? Sorry, so you don’t think a stream of emoji is a particularly useful app Hey, that’s not great news team What are you what are you doing Kat? KAT FANG: I’m coding MIKE MCDONALD: Can you speed that up? We have five minutes before our– KAT FANG: I’m done, I’m done MIKE MCDONALD: You’re done? How did you finish so fast? KAT FANG: I’m really quick MIKE MCDONALD: OK Well, let’s see what Kat did So we need to prove to our investors that this app has traction So I need everyone in the audience to go to,

it’s mosaic with a “j,” cause that makes sense, and start playing around with the app Can we switch back to screen number one, please? Let’s take a look at what Kat whipped up in that 30 seconds That was really impressive, Kat KAT FANG: Yeah MIKE MCDONALD: Can we get screen one, please? Or everyone, go to, sign in with your Google account, and what’s happening is, you take a photo, we use our proprietary emojification algorithm to generate the stream of emojis And then, I was talking to some of our investors earlier and they told me that mobile social viral gaming is really popular for some reason So I guess that’s what Kat did She created a social game where you build– thank you, all, by the way, for helping fill this in– a larger emoji because that’s what the world needs So hopefully, this goes well and we’ll be able to get a giant ball pit full of gummy bears at our startup Thank you all very much and enjoy the rest of I/O [APPLAUSE] [MUSIC PLAYING]