字幕列表 影片播放 列印英文字幕 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.