 Hi, everyone, I'm Michael Blyve with Firebase. And I love using the platform to build web applications. It's amazing the way that you can compose simple elements together, and it becomes a fast, responsive, fluid front end for your web application. But on the back end, the story is a little bit different. Sure, it starts out easy. I think I'll just throw some code together, plug it into my front end, and everything will be good to go. So let's start with something like auth, right? Well, let's see. I want to have signed in from Facebook. So that's OAuth 2, but I want to support Twitter as well. That's OAuth 1. Then I want people to be able to link both of those accounts together. And I guess I'll need a database. So let's see, Postgres or MongoDB. Let's see. Then I need to build API servers that talk to the database, and then the clients can talk to those. But my API servers have to scale as my application grows. OK, so that's the database. Oh, wait, but I want it to be real-time. So that means that I also have to run socket servers that sync the changes from one client to another client whenever a change happens. And let's see, yeah. And I need to build an administrative back end so that I can look at the data in my system and make changes. And yeah, so there's my back end. Great, except actually that's not my back end at all. That's just all of the scaffolding that's required to start building my back end. So I know what you all must be thinking. There has to be a better way, right? Well, thankfully there is Firebase. Firebase is an integrated suite of products that helps you develop your app, grow your user base, and earn more money. Now, with Firebase, you can do more than just use the platform. You can use the platform and lose the back end. Are you tired of implementing the same authentication system again and again? Firebase off makes all that go away. With one step, you can have authentication with Facebook, Twitter, Google, email and password. It all just works. It's 2016, and users expect more from their applications. Pull to refresh is unacceptable. Pulling is slow and unoptimized. If you want real time, you have to build a complicated back end, right? Not anymore. The Firebase real time database takes all that pain away. Connect to the database directly from the browser. Sync changes in real time to every connected client. Take all of those refresh troubles and throw them away. Now, have you ever been in the situation where you spin up a server just to proxy traffic from file uploads from the client to your server and then to a cloud storage bucket? Not anymore. Firebase Storage lets your users upload directly to Google Cloud Storage from the browser. And you still have total control over who uploads what and where. So now we've got Firebase Auth, Firebase real time database, and Firebase Storage. We've replaced our entire application back end. And that's pretty great, right? But we still need to deploy our app somewhere. If only there were a way. Firebase Hosting. Firebase Hosting allows you to deploy with a single command line, with a single command from the Firebase CLI, and in seconds, your site is deployed to a global CDN with HTTP2 support. If you've heard of Purple, Firebase Hosting is one of the easiest ways to get started with Purple. So this is a pretty great platform. I started working for Firebase a little bit more than a year ago. And if I weren't working for Firebase, I'd still be building apps using Firebase, because I think it's a great platform. So this is like all we need, right? We have everything we need to build an app. But wait, there's more. I first heard about web push, and I was really excited. Because to me, web push was one of the biggest gaps in capability between native mobile applications and web applications. Those push notifications made it really easy for people to get right back into an app really quickly. So I saw web push, and I thought, great, I'm going to dive right in. I'm going to implement web push. And it's going to be really easy. And then I read how you actually do it, and I gave up almost immediately. I think it was the elliptic curve digital signature key pair where I just really threw in the towel. So again, there has to be a better way, right? So now I'm pleased to announce that Firebase Cloud Messaging, the same service that powers more than a million applications and sends messages to more than 2 billion devices worldwide on Android and iOS, has come to the web. We've taken that 15-step process, and we've distilled it down to three. Install the Firebase Messaging service worker, ask the user for permission to send notifications, and then listen for those notifications. It's really that simple. But why are these push messages so important? Well, we've been trying out Firebase Cloud Messaging with a few early partners, like Aliexpress and Alibaba.com. And what they've seen is huge upticks in engagement. In fact, they've even seen some engagement that surpasses the same conversion rates on their native applications. And that's a huge difference, because with web push, you can just engage people where they are. You can get them back into your application faster and easier. So that's a complete platform, five features that all work together to deliver a comprehensive platform, a comprehensive back end for your web application. But wait, Michael, I hear you saying, this is the Polymer Summit. What does any of this have to do with Polymer? Well, that's where PolymerFire comes in. PolymerFire is the official set of custom elements built by the Polymer and Firebase teams together to support Firebase and web components being used together. And I'm happy to announce that with the O.10 release that's coming out later today, you'll be able to use Firebase Messaging in PolymerFire directly. Now, this all can be yours with one easy step of Bower install, save Firebase PolymerFire, try it today. OK, OK, sorry. I get a little bit excited when I talk about Firebase. I think maybe I got carried away. But I am really excited about Firebase. And I'm really excited about web components. It's two things that I think just fit together really naturally. And now I'm going to take a step back. And I'm going to look at how you can actually integrate these two things together and how you can build a full progressive web application using Polymer and Firebase together. And I'm going to start with a demo. So I built a little app called PB&J. It's a restaurant delivery app where you can see a restaurant's menu, you can order some food, and then you can watch the order status. So let's go ahead and switch to a demo. So here we have the beautiful website for my favorite restaurant, that's my jam. And you can see on it I have a link that says order on PB&J, so I'm going to go ahead and tap that. And here's the menu, I've just got some different peanut butter and jelly sandwiches. And so I'll add a few of each of those. OK, I don't need six sandwiches. I'll just go with two banana PB&Js. That sounds pretty good. And let's see, now it says I need to sign in, so let's go ahead and do that. And of course, I'm talking Firebase off here. Quick pop over to Google, tap my username. There we go, I've already got my address stored with my user account. And now you can see I've got a checkbox for order update notifications. And when I tap that, you'll notice that it immediately pops up a permission dialogue that says, do you want to be able to take notifications? Let's say yes, and let's complete our order. So now the order is received, and hopefully my delicious food is on the way. Now I'm just going to step over here to my laptop for no apparent reason. And oh, what's this? Now my order is on the way, and you might have noticed that a little message popped up at the bottom. So that is actually Firebase Cloud Messaging at work. It went from the cloud to my device and popped up a notification. But hey, there's a million ways that you can do that, right? You can do that with the Firebase Real-Time Database. So let's say that I am not in the app anymore. In fact, let's say that I exit it completely. And now it's been a little while longer, and I'm thinking, I'm really hungry for some PB and J and bananas. When is that food going to get here? And oh, look at that. I have a notification on my phone. What a surprise that I was not expecting. And you can see PB and J is arriving now. Your PB and J food is arriving. I tap the notification. And it brings me right back into the application, and you can see, hey, my orders are arriving soon. So that's PB and J. It's a really simple app, but it shows the power of Firebase. We use the database to store this data. We used Auth to sign in with Google, and we used Firebase Cloud Messaging to push these notifications out to the user when they were relevant. Can you imagine how easy this flow is compared to installing a native application for every restaurant or for 10 different delivery services that are all competing for the same space? This flow is a game changer, and I think that it's really cool and really important. So let's go ahead and switch back to the slides and talk about how we built this. So with Polymer Fire, everything starts with the Firebase app element. The Firebase app element is essentially just a way to bootstrap the configuration of your Firebase application, aptly named. And if you've used Firebase before, you may have seen a snippet that looks something like this. And Firebase app is just literally executing exactly the same code. In fact, if there is a reason that this is more convenient for you to do just because you can copy and paste it from the Firebase dashboard, use this instead. It really doesn't matter. They do the same thing. And the fact that they do the same thing is actually kind of handy, because that means that you can use the Firebase JavaScript SDK exactly the way that you do in the docs from anywhere in your Polymer app. So sometimes elements are the right way to go, but sometimes you want to drop down to the JavaScript SDK. You don't have to pick and choose. This isn't some sort of buy-in to everything, and it all works this way. Just use the Firebase JavaScript SDK where it makes sense, and use the custom elements of Polymer Fire where it makes sense. So in this case, Firebase Storage, which we're still working on for Polymer Fire, can still be used in my Polymer app just by dropping down to the JavaScript SDK. So next, let's talk about Firebase Auth. Firebase Auth is an element that lets you synchronize your current user state and also gives you easy hooks to sign in your users into your application. So let's take a look at the Firebase Auth element. Here you can see that I gave it an ID, and I'm binding two properties from the element. I'm binding the user property and status known. Status known is basically saying, hey, Firebase has done the due diligence it needs to do to figure out, and now we know whether or not the user is logged in. And user is going to be the currently logged in user if there is one, or it's going to be null if there isn't. Now one feature of Firebase Auth that I want to highlight today is the idea of anonymous authentication. Because when a user visits your website for the first time, they're not always looking to just immediately hand you their email and create a new password, or even sign in with Facebook or another social authentication provider. But a lot of times, you still want to be able to associate data with them as they go through and add items to a restaurant order or anything else. That's what Firebase Auth anonymous authentication allows you to do. So here, I'm setting an observer on user and status known, and I'm calling a method called autoauth. And what autoauth does is just says, if we know that the user is not logged in, then let's go ahead and automatically log them in with an anonymous account. We don't need any credentials from the user. We don't need anything else. The account is stored on the device, and now you can sync with the real-time database. You can do all the things you would do with the user, and you know that this is anonymous user. In the security rules and other places, you can see is anonymous is true. And what's really useful about this is that later, maybe a user has become engaged with my application, and now they're ready to upgrade to a full account. And that's really easy with Firebase Auth. So all I do here is I say, OK, I'm going to use a Google Auth provider, and then I take my user, which is directly pulled out of the Firebase Auth element, and I say, link with popup and the Google provider. And that's exactly what happened in the demo app that you saw. It takes you away to Google. It comes back, and it actually authenticates you with the same UID that you were already using from your anonymous account. It links those accounts. And it's not just one to one. You can link as many providers as you want to the same account, which means that if you want somebody to be able to associate their Twitter, their GitHub, their Facebook, all of those accounts with the same user, you can do that with Firebase. Next, let's talk about the real-time database. And the first element that we use for that is Firebase Document. So Firebase Document is essentially just listening to a path in your Firebase database. If you haven't worked with Firebase real-time database before, it's essentially a giant JSON object. It's a tree of data at which at any point you may have leaf nodes that are just JSON values. So it could be a string or a number or any number of things. Well, actually not any number of things, because JSON's pretty limited. That number of things. So with Firebase Document, I can just bind to a path in the Firebase database. In this case, I'm binding to a user profile. And you'll notice that the user UID is bound into the path. And Firebase Document is smart enough that if you have a path segment that ends up with two slashes in a row, it's not going to bind that, because it assumes there is a missing binding there. So you can safely add this element into your project. You can bind it with attributes and properties that are null, and as soon as they're populated, the Firebase Document will say, OK, now everything seems to be here, so I can go out and I can actually fetch the data. And that data is being synced into a property called profile. And of course, because this is a polymer element, it's built to work with the polymer binding system. So if I have a text area, for instance, I can just directly bind that into profile.address. As I type into that text area, it syncs in real time to the database. Anyone else who's looking at that same data will see all those changes happen in real time. It's really easy. It's almost stupidly easy to do. But sometimes you have data that's a little bit more complicated than just a simple document. And that's where Firebase Query comes in. Let's take the menu from the PB&J app, for example. The data for that looks something like this. You have a menu. Underneath that, you have URL-friendly names for each of the menu items. And then underneath that, you have the description, image, name, position, and price. So how are we going to get that into something that Polymer can look at? Because if we used Firebase document for this, we would just have an object. And it's kind of hard to deal with objects and turn them into lists. And there's kind of a lot of work there. So that's where Firebase Query comes in. With Firebase Query, again, I just have the simple path and data. So I'm binding to a path in the Firebase real time database, in this case that menu. And underneath that menu, there were nodes for each of the items. And I'm, again, binding the data into a property called items. And the one extra thing that I'm adding here is order by child. So this is one of a few different querying attributes that you can add. And in this case, I'm saying that this position property that's in my data is what I want to order by. So if I have position 1, 2, 3, 4, 5, then it'll order by that. And then below this, I'm just using a standard iron list. And I'm binding it in there. And the only difference that you'll see is that there's an item.$key. And that's automatically added by Firebase Query to tell you what the key was. So in this case, classic-pbj or whatever else it is, so that you can turn this object into an array without losing any data or granularity. So Firebase Query makes it really easy to read collection-based data out of your Firebase real-time database. Next, let's go into Firebase Messaging a little bit, because it's the newest thing. And I'm pretty excited about it. So essentially, what Firebase Messaging lets you do is send messages to your application whether or not it's open. And so to start, you're going to need to install the Firebase Messaging service worker or use a service worker that you're already using in your web app. And it's really not very much because service worker is required for doing any kind of background action while the site is closed. We have to have a service worker, but we've done a lot of work to make this as easy as possible. And so all you have to do is import the Firebase SDK, initialize it with your Messaging sender ID, and then initialize the Messaging SDK by calling Firebase.messaging. Now, optionally, you can set a background message handler in the service worker that allows you to manually handle any messages that come in. But in general, you won't need to do this for reasons that I'm about to go into. So this is there as an option for advanced use cases, but most of the time, you probably won't need it. Now, let's talk about the Firebase Messaging element a little bit, because there's a couple steps that you have to go through to get Firebase Messaging working. First, you have the element itself, obviously. And here I am binding a property of token, and I'm adding an event handler for onMessage. And so let's talk about the token first. Notifications require permissions. Browsers don't just allow any site that you visit to send you push notifications, and that's a very good thing. But obviously, you need to request permission then if you're going to do it. That's baked into both Firebase Messaging and the Firebase Messaging element. And so all I have to do is take my Messaging element and call requestPermission on it. And that's going to pop up that little permission dialogue just like you saw in the demo. But of course, if I already have permission, then it's not going to pop up that dialogue, and it's just going to return a promise that will automatically resolve, and the Firebase Messaging handler will automatically set all of this stuff up. So I request permission, and in this code here, I'm doing it onReady in my element. But that's not actually what I'd want to do in my application. I'd want to attach it to a user action like you saw in the demo, because you don't want to just have somebody visit your site and then, wham, immediately they're hit with a, hey, allow me to send you notifications. That's a pretty bad user experience, and people are probably going to hit back as fast as they can. So instead, tie this to a user action, make it something that's really clear, like, I want notifications, and now I have notifications. And that's pretty easy to do. So how do we actually send messages? Well, we need a token. So when Firebase Messaging registers successfully, it gets a device token that you can sync to the real-time database or anywhere else that you can access so that you can send that specific device a message. So here, I'm syncing it to the real-time database under prefs.pushToken. You can do anything you want with this data, but you need to have this token to be able to send messages to that device. And so what does sending a message to a device look like? It's a simple HTTP request. You just post to fcm.googleapis.com, slash fcm slash send. There is a server key that you have to paste in from your Firebase console, and you need to specify a content type of application JSON. And then the body just says to, and you specify the token. So that's pretty easy, but then what's the actual payload? So there are two different kinds of payload that you can do. You can add a data payload, and this is just basically a silent push. So this is going to be sent to the device, but isn't going to trigger any kind of visual notification unless you decide to write custom code that does that. And so this can be useful for sending something to the service worker to let it know it needs to update something or just other actions that do background processing but don't necessarily pop up a notification. But where Firebase Cloud Messaging gets really smart and really shines is with the notification payload. So you can specify a notification payload with a title, a body, a click action, and an icon. And that gets turned into that native notification that you saw in the demo. But more importantly than that, it's also smart about what is the current state of the application. Now you'll notice that the first time I sent a notification, it just popped up as a toast in my application. And I wrote code to handle that because what happens is that Firebase Cloud Messaging assumes that if your app is in the foreground, then you probably don't want to push notification to show up in the notification tray because you're literally looking at the application right now. So rather than popping up that notification, it will instead send through a message to your Firebase Messaging event handler, and you can decide if there's some kind of UI that you want to do. Or if whatever state the notification is telling you about is already represented on the screen, maybe you'll do nothing. But if the app is in the background, and that could be that you are switched over to a different app, that could be that you're on a desktop and the tab is no longer in the foreground, that could be that the app is entirely closed, then it's going to pop up that native notification, and you're going to be able to jump right back into the app and pick up where you left off based on the URL specified in the click action. So this is a really simple API, but it's also really powerful. It lets you reengage users at whatever seems like the right level, and it's not going to bug them with incessant notifications if they're already looking at the app. In addition, because this notification payload will automatically pop up a notification, you can do this without changing your code. So if there's some new kind of notification that you want to try out, and you don't want to have to deploy new code for it, and you're just testing things out, you can send this to devices exactly as is with no extra code, and it will pop up a native notification. And that's pretty cool. So going back into our code, we're going to actually handle this message now. So you can see I have an on message, and I'm calling pushReceived. And that pushReceived then just gets an event, the detail of which has a message property in it. And of course, message is exactly what we said. It is the message payload from this slide. So you're going to have that notification title body. All of that is going to show up in the message.notification. If it's a data push, then it will show up in data. And that's all there is to it. So with just a little bit of work and a really simple API, you can integrate this push messaging into your progressive web application using Firebase and Polymer together. So that's kind of an overview of what you can do with Polymer and Firebase. Polymer gives you amazing web component front-end technology that makes it really easy to compose apps from simple components. And Firebase does the same thing by letting you compose complex apps from simple back-end components so that you don't have to run your own servers. This isn't what we want to be building. We don't want to spend all of our time connecting together and re-implementing the same things that have been re-implemented 100 times before, 1,000 times before. We want to concentrate on the things that make our apps great, that make our apps different. And every minute that you spend writing a bunch of boiler plate that doesn't really need to happen is a minute that I wish could be spent building your app instead. So do yourself a favor, make yourself a nice Polymer butter and Firebase Jelly sandwich, use the platform, and lose the back-end. Thank you very much.