Duration 40:31
16+
Play
Video

Build planetary scale apps with Firebase

Sarah Allen
Product-Focused Technical Leader at Google
+ 1 speaker
  • Video
  • Table of contents
  • Video
2018 Google I/O
May 8, 2018, Mountain View, USA
2018 Google I/O
Request Q&A
Video
Build planetary scale apps with Firebase
Available
In cart
Free
Free
Free
Free
Free
Free
Add to favorites
6.41 K
I like 0
I dislike 0
Available
In cart
Free
Free
Free
Free
Free
Free
  • Description
  • Transcript
  • Discussion

About speakers

Sarah Allen
Product-Focused Technical Leader at Google
Doug Stevenson
Developer Advocate at Google

Sarah Allen created early web platforms for realtime apps with Shockwave and Flash Media Server. She led the mobile development company, Blazing Cloud, developing many native mobile and web apps. She now leads Google Cloud Platform infrastructure teams working on server-side events and security policy. Sarah believes that software should be seriously fun, and that there is magic is in making powerful tools that spark imagination and challenge us all to keep learning and inventing.

View the profile

Doug is a veteran engineer, experienced public speaker, and developer advocate at Google with the Firebase team. He's been developing for Android since the very first Android device was on the market, and has bootstrapped the efforts of silicon valley startups. Outside of work, Doug follows professional ice hockey and enjoys craft beer.

View the profile

About the talk

Join this session to see how Firebase scales to keep pace with your app's rapid growth. Learn how you can build a solid foundation with Cloud Firestore and Cloud Storage, and create a scalable serverless backend with Cloud Functions. We’ll deep dive into how to model your data with Firestore which performs as well when you first build the app as when you have users across the world, and drive growth with Cloud Functions.

Share

My name is Doug Stevenson. I'm a developer Advocate with the Firebase team manager Google and I'm super excited. I actually got a chance to codon some of the technology that will be talking about today. So planetary scale apps with Firebase is what we're talking about today, and that means huge dataset billions of people across the planet using your app. This talk is really for two kinds of people. Some of you may be already have a planet scale app. and you're thinking I have so much going on. How could I possibly use a new technology?

It's very hard. Even though everybody wants to do that with some of the Technologies were talking about today. There's an opportunity to reduce the OPP's burden and and add features more quickly increase your velocity the other kind of person and I think he speaks to everyone of us we have in the back of our minds were our Forefront of our minds a world-changing idea something that is a small laugh now or a small idea wanting to be a nap vet. Aspires to be a planet Scale app

and I really excited to share some of the technologies that can let you build small and grow big. Specifically what I mean by planetary scale, so this is the technology to help you reach every person on the planet potentially connecting to four billion people that are now connected to the internet. With lots of data. So anytime you have a lot of users you have a lot of data. Sometimes you have fewer users in a lot of data and it's too big to fit on one hard drive. It's complicated

sometimes to design queries to get the date of you want that is responsive and quick and you want your data to be close to the edge. So wherever on the planet your users are the day to get to them quickly. So I describe some of the challenges but the good news is with a mobile or web app. No matter what technology you're using. You only need to fetch the amount of data fits on a screen or maybe a few screens. And so this is a hard problem to get right but it's a totally solvable problem because it's constrained by the amount

of data a human can see on a screen. So in this talk will show two examples of planetary scale apps one is a real world use case. So an app that maybe you use maybe already used it today and there's an app that we built for you today. Where did we finish this demo and we'll open source that later so you can explore it on your own at your own time. So the toilet we use well that both the other app that will show you later in both use they both have in common is cloud firestore. So cloud firestore is a massively scalable nosql database is cloud-hosted. So all your data

lives in the cloud if you're using fire store and how is it scalable? Well, what what does it mean by mass of a scalable? Well, the idea is that you when you query it you want to Corey the day that you get out of it. The performance is based on the side. Of your results at so the what you Corey out of it determines the performance. So what does that mean to say? You have 50 documents in a day or so you have a thousand documents in the database and you Corey 450 that's not a very hard problem with the performance is based on the 50 that you Corey for know. What if you have a hundred thousand

items in your in your database. Well, as long as you're still wearing 450 the performances at exactly the same and what about a hundred million? Well still with fire store its scale such that if you're pouring 450 documents within that hundred million, you're still getting the same performance it it's scales massively not with the size of your entire data, but with the size of your results set for your query, there is no sharting. There's no maintenance. You just write the queries. I feel like the database, of course then write queries on top of that. So I'm really excited to share with

you our first use case, which is Evernote with their hundreds of thousands of users. They currently support a lot of infrastructure. They were looking for a wage increase our velocity lower their Ops burden and deliver new features to their customers all of the same time. When we met with them, they mentioned some of the primary reasons for choosing firestore. These aren't the same ones that everybody picks and I thought they was this was really insightful. They are really excited about the offline support. So the client sdks allow for

writing when you're disconnected and then automatically syncing to the server when you get back online also, there's notification of change across multiple devices and the consistent apis across the client sdks really really speed development and they're super excited about that. So in addition to sharing notes Evernote users often use multiple devices, they might use their desktop app and their mobile app at the same time, or maybe they use their desktop app at work and then at home, they use your tablet and they people more and more expect this kind of

seamless experience, but particularly with this app where everybody Keeping their they're really important personal data and observations on the world. So before we dive into that, I wanted to take a moment and tell you about Firebase rules and this is really a key part of makes what makes fire store and all of the Firebase accessible data storage options Really Work Well, normally you need a server in between your client and your server side data because you can't just like have those queries open to the world. You have to

do some authorization. You have to do some things that you just normally have to do. They're not fancy. They're just stuff that is important. And so with Firebase Firebase rules is a simple declarative send tax that you just upload to the server and that says which of your data pass are accessible. So only authorized users can read and write certain documents. You can also have public data you can have dated is not accessible at all, except on the server side. You do a validation where you limit the Length of a string or going to make sure about integers are

within a valid range start date of modeling is kind of a particular. So it's derived from what we learn from users of Firebase real-time database. So for those of you who have already use that, you know, it's also a cloud hosted nosql database what we didn't we observe what developers were doing with it found some patterns some best practices. What we did is we tried to code that into the structuring of fire store. So you'll see is it a common most common use cases. So

what you have is at the very top level of your Firebase you have collections and these collections are containers for documents. You have to organize your documents into collections document is the lowest level a unit of data. So there is nothing really smaller than a document a document can have fields in it. Those fields can have type. Do you read a document you're getting all those fields? All those datatypes all in one query now within a collection the documents can be ordered and they can be filtered based on the content. So if you have fields in there that you want to use to narrow

down your search for order by say date or some count or something like that. You can perform Cory's like that and like I said that scales with the size of your results set. So I'm really excited that Evernote decided that they were willing to share a bit about how their data is modeled and they are some common patterns. So this give you a sense of how firestore data modeling works. So you have a top-level connect collection of all the users when somebody logs in then

they the client write this date or whatever you use your data that they signed up with and and then you have your basic profile information from then on that's cash locally on the device and when you reconnect that listens for changes from the server so that if you got that if you connected on a different device and change your profile, it would automatically sync. So then they organize data in your notes and notebooks and spaces and those from the client side and there's another top-level collect collection of all your notes Susan a

common pattern for how firestore organize of these days you have these top-level collections. We can have a huge number of documents, but the individual user is only getting a small subset of them. And therefore you can have that results at be small and your queries be fast so that the client listens to the notes that they have access to and then when they change it automatically sync across devices and between users and then Firebase rules works on the server side to make sure that people can only access what they're supposed to have access to keeping user

data safe. Now you might be wondering what did we build? Well, our use case is a little bit different than Evernote. Actually just a web app. We calling it The Friendly shop and the idea here is and this is totally fictional course companies all over the world can upload images with inspirational quotes. So you can think of that kind of like a shop in the ideas that you can go and browse them and maybe buy them between the Evernote case and our case is that we don't need to show all the documents, you know, you show all the items together. We only need the show what can

fit on the screen or in this case for showing 50 items for Corey. So what we'll do is we'll dive into this a little bit. The idea is what are our Hope was we wanted to put a million documents in there. We were targeting a million. But how many of the do we actually get to unfortunately. We are about $260,260 today and that's just because we were planning on a million we didn't quite get there. You tell about some of that the guy just ran into not a limitation of the scale of Google storage or anything like that or lack of planning really

busy as I'm for adding features at the last minute. So, what did we what do we use to build it? Well, obviously we used tire store like we mentioned earlier but we used a variety of Firebase in Cloud products to build this out. And what we didn't have to do here is stand up a server configure it log into it. We didn't have to scale it all just happen automatically. So first one tell you about our second cuz you very talk about fire store Firebase hosting whenever for web app is in the course essential. But whenever you have a mobile app, typically you'll have at least a few screens that you

want to deliver on the web and you want to be able to easily serve up all your static assets HTML CSS JavaScript and images and and then you also want to be able to do this globally and have those accessible close to the edge and Firebase hosting is a global content delivery network with physical address all over the world so mad no matter where users are they get they get low latency which turns into speed for the user experience definition of tactfully

that we used is Firebase authentication. We use just a just a tiny sliver of it with Firebase authentication. Does it helps you get your users login to your location supports Google login Facebook Twitter and more that's not enough to suit your own planetary scale needs. You can write your own plug-in. So if you have your own authentication provider your own users your own o a system, you can plug that in yourself, and that's fine. So cloud storage each poster has its own image and we need a massively scalable data storage

place to put them react. You don't need something quite as massive his cloud storage, but it's good to know it's there. So the images can actually get pretty big and there's room to have extra thumbnails and variance across the devices and let me tell you a little bit about how big Google Cloud Storage is its exabytes of data had to look up what an exabyte is in its big bites with 18 zeros after it and roughly a million terabytes and I don't know if anybody is old enough to remember we had to worry about physical discs and if things were to

get bigger and bigger disc, so that was like really exciting and then if your stuff had to go in local disk, that's a lot of work and it's so lovely not to have to worry about that and not to have to plan for that to be in the future. And so whether our poster app, even if we were storing a really high res image that was like 10, maybe I could start trillions of those and that's really delightful and I think that it'll work for a friendly shop. Even if we get to planet scale with our user base. R

and the last component that we used to kind of wrap all these different products up is called Cloud functions. So what's up functions? What we have is a serverless back in compute container. It's built on top of know Jessica managed nodejs environments. All you do is Right node write JavaScript deployed to Cloud functions and it runs in response to events that happened in your system. Now, what are those events that happened? Well, for example, what we could do it a wrap is when a new user signs up you can automatically turn around write some code in credit use a record for them or

anytime a new Doc is that is at its throat like someone upload the new poster. What we can do is automatically kick-off some process to generate thumbnail that are appropriately sized for a web app, or if I don't have a third case, but the point is we we all you do is right at the play that code you don't manage any service you don't log into anything and best of all you don't scale it up or down it automatically scales up to meet the demand of your system and automatically scale. Down 2-0 if all of your demand goes away, so you only pay for what you use you

don't have all the servers hundreds of service fired up paying for them all the time. You only pay the computer resources that you actually is in in this product all actually live add one new function that will add some functionality to our app without having to deploy a new version of the web app. So I'm excited to show you that if it works. So this is a truly serverless experience which significantly since simplifies both your development and your operations there these illustrates how these all work together to

power. Our friendly Shop app is no servers. No VM to manage. You can do capacity planning on a napkin. And having this flea medicine for structure means we can focus more on our application features and that is really what drives the business value for. Our friendly shop one place that we do need to do some careful thinking as you mentioned before is Howard data data is modeled. It's not automatic. You have to think about your use case and and how you going to put that data together and fire store is structured to help you think

through that and organize your data for scale. So I want to dive into the fire store experience. This is an image of Omar from the data console in the Firebase UI from our friendly shop data store. Data structures and I'll just walk you through the interface which also walks you through our data structure. So if you ask for more real you would probably have more connections collections on the 1st panel on the left you'll see items so that will show a list of collections normally have

items users what not and you can also add collect hysterectomy interface. So be able to direct as in the in the interface sometimes means that you can get started on the view of your app without before you build all of the interaction into your app. The next column is a list of documents for the selective collection. And here we have in a 250000 plus documents and you could actually scroll through all of those you can also snap to a particular ID and picking a particular document and then when you select the

document its contents On the right and here is some of the data or all of the data for our all the metadata for each of the posters in our shop and you can also are apis into this. But if you want to structure your data more and deeper, you can control how much you ask for the time by creating subcollection so you can see there that you can add a collection as well. Although our app has a fairly simple but flexible data model with just a top-level collection. You hold on to that one?

So here is how you Corey the database. It's just a simple few lines of JavaScript. If you go and view the source will get something like this. Although it's a little bit broken out. What we do here is reusing the Firebase SDK JavaScript SDK. We're reaching into the fire store product for that. So Firebase has a bunch of different products bundled and we're just interested in the fire store right here in the reach into the items collection in the work order all those items all two hundred sixty thousand of them by Price descending so we get the most expensive one first and the

least expensive ones last and they were going to limit by the first 50 the top 50 again based on the ordering they're going to get that's a synchronous and once we get those 50 results will render them to the screen. This is actually how we populate the home screen for are at so why don't I jump into a dumb advances slide will jump into the demo. Okay, so it actually if you wanted him alive to see that short link up there that bit ly link go ahead and copy that in your mobile browser or your desk or your laptop. You can actually follow along with me. So what I'll do is I'll copy

this and paste into them to browser. And it loads up. And we have results. So here is 50 some the top 50 sorted by price. We have all the expensive ones here everything he was 2599. I can actually turn around and reverse that sort if I want. And now we have the cheap ones. I'm a budget Shopper. So I'm going to keep it on the on the cheapest ones first. So that's how we populate the home screen pretty straightforward. Could we go back to the slides place? So what do you want to add an additional query cuz he want to

add filters we can. Specify another where Clause so in this case, we are we want to filter by topic so we can say we're a topic equals whatever the user is fixing the interface and then compared to the prior query is in grey and the the new part is highlighted and this is just another option in the query Builder that life is filled to the results. So let's go back to the demo and see what that looks like in the app. Okay. So what I'll do now is let's choose a topic and these topics for

a randomly-generated. We used a node module called Faker and Baker generated all this sort of like business. He sounding thing so it's all sort of tongue and cheek head of humerus. I'm totally into E-Business. So I'm going to I'm going to do any business and then the results come in his notice at the quarries are just as fast as all the others adding and didn't actually impact performance of this but now we can see that we have all these business posters and I can go in there and change that again. I'm I'm also totally into platforms. How about platforms

exactly the same no matter how many where Clauses we had so we'll go back to the slides. So now we want to add another filter. We do it in an intuitive Way by adding another where Clause so these on particular poster images have a range of colors. And so we can choose top 50 posters sorted by Price starting with the most expensive and then for particular topic and a particular color we can see the results set. Yeah, so that's so let's go to the demo again. All right. So you saw in the last page that bit of code does to wear clothes that they're being logically and it together. So if I want to

look for posters that are on the topic platforms and are in let's leave orange because that's the closest thing to Firebase. So let's look at all the ones that are orange and again we get now. Oh that's actually really attractive. So again, you noticed we made the Quarry more complex by adding another wear clothes. But again. Corey took just the same amount of time cuz it's the same 50 size results at remember. Where is Scale based on the size of the results at not on the source data set? Oh nice, I should have added or I should have mentioned earlier. We actually have a script over

here. That's constantly adding New Hope now you can see it at a new one. So this is actually simulating what users might actually be doing imagine. There's users all of the world constantly adding new documents. That's what the script back here is is doing so the result set that you see on screen or that you're seeing your mouth what could actually change over time? So this isn't just a static results at this is a constantly changing results. It becomes significant later on though. It's switch back to the slides. So you can keep doing this

and we could go through another one and another one and another one and keep making up variations of our posters you get the idea by now. So the only requirement is that when you're doing these Composite Index has that you create a query that you get a you create a composite index. And so that allows you to support all the combinations of filters and ordering that you need. So we have another demo. Oh, no, we are now so you can keep adding where Clauses to

your heart's content, but you're only constraint here is that you have to add indexes for them. So what you see here is a screenshot of what it looks like in the Firebase console for the index this week that it so you can see we've got all the combinations of things. We want to filter in order by as long as all these indexes exist. Aries will be fast right and do something you have to do when you create an index. It will just go off and do it. You can also put these in a configuration file and deploy them with your app. So you don't have to manually create in any one of these about the

interesting thing here is that if you don't if you forget to create an index and you try to Corey on it Firebase firestore, we'll say well I'm not going to do that Corey because it doesn't scale. I only do scalable things. But what I will do is give you a very interesting error message in the console. So, this is an actual error message what firestore SDK is showing you it says they require Corey requires an index. You can create it here and it gives you a link to go create that index. You don't have to like know any sort of magical incantations. You just click the link that takes you

to the Firebase console and makes an index for you. So during development. If you forget to think of all the different combinations of things you want a quarian. You can just create one ad hoc. I think that's really amazing. This is maybe the most actual error message you will ever see in SEK to literally telling you how to thank you. Thank you. Firebase is easy to use. Just wrapping up a scalable queries as Doug has just demonstrated indexing Made Easy. All of your individual field

fields are index by default. If you're just doing a very simple query on a single property. You don't have to do anything and then for compound queries, we have Little Helper there. So I think you've seen lots of different demonstrations of how performance is based on the results set. And we have a lot of great documentation on how to structure your data. We've gone through some really common patterns today. And once you get a feel for it, then you can put together these at these really scalable apps.

So we can also expand or app on the server side in a different way with Cloud functions. We talked about two different data storage ways to scale your app with fire store and was cloudy with cloud storage and with Cloud functions. You can provide service I'd code you can do a lot with Barbies with the only side code but server cut side code can be helpful for we have three things shown on the slide, which is like some data wrangling you might when you're creating your profile while I get some stuff from like social

sharing sites or figure out who people's friends. Are you might have some business logic to drive user growth with a shopping frenzy and you often have to do a whole bunch of media wrangling creating thumbnails and and various on images. The other kinds of things that people do with Cloud functions is put code on the server and client. 2 in order to make Fair decisions in order to be really careful with that business logic and protect that so it's not kind of in the wild in an untrusted client, but secure on the server side,

and then it's also a great way to do a multi-party interactions to create a bot to coordinate many users at the same time. So car functions has support for a bunch of different event providers within the Google infrastructure. So you've already seen fire store in real-time data protection. We haven't seen it yet. We've we've mentioned Firestorm real-time database. What you can do with Cloud functions is Right triggers that respond to changes within your database do in fire store. If a document is created or changed or deleted you can write code to respond to that

same thing as real-time database. If something changes anywhere within the hierarchy that matches a pattern that that you that you define you can write some code. So this is good for doing things like data sanitization. If you want to change the value that's invalid at the time of insertion. You can do that with the club function with Firebase authentication triggers. You can write code that that runs when someone knew it was in your system. So if there's a new account created you could go often create a profile for the work that account is deleted you can clean up all their data. So

you're not paying for extra storage for user that no longer exist analytics triggers. You can write code that triggers in response to convey. Event. So a typical conversion event is if someone buys something or someone perform some sort of high-profile action within your app. You can write some code to respond to that. Keep track of it on the back in cloud storage. But you write code that responds to when files are uploaded or changed within your cloud storage bucket. So an AR app if a poster was uploaded we could write some code that creates the thumbnails of various sizes that are

appropriate and all in response to the upload. We don't have to do anything else. It just happens automatically can also use cloud pubsub. So whenever a message was published on a pub sub topic you can write some code to respond to that also, you can use crashlytics. So if you're using crashlytics in your iOS or Android app those events can get triggered through Cloud functions as well so you can get what's called velocity alerts to know if an error happens and how severe it is among all of your users for your apps and lastly there is HTTP trigger so you can write code. That's basically I'm

in API endpoint a webhook of some sort. So you can use this to create Bots as Sarah said you can use this to Crate rest apis for your everything even if you just want to Something like populated database, which we'll talk about a little bit later. So let's switch to the demo again. Okay. So remember before there was that script that was populating the database and this has been going on about every minute or so. It adds a new poster. Now, this is simulating what users might do if it's not the real thing. Let's say I want to drive traffic to my website by

creating a trigger that responds to win a new posters upload. What I want to do is tweet that out to everyone after a look at our new poster so I can do that without changing any of the web app code. So what I'll do is fire at My editor here in this is my cloud functions code already having my coffee pot for a that's not it How about this one? I'm always prepared. All right. So this is our new function. I will walk through a sort of redacted version of it. So if we can do actually let's not switch just yet. What I'm going to do is deploy it and while that's the plan

maybe it will pick up one of the posters that's being created by the script so we could switch back to the slides now. So this is kind of a stripped-down version of what basically dysfunction is doing were using three sdks industry using the functions. I speak a word using the Firebase admin SDK which gives you programmatic access to all of your fire base features Twitter SDK as well. Of course, we're going to go through initialize the admin SDK initialize the Twitter SDK. And then in the body of the function where to find a new function, so we're going to call the Tweet new

items to say hey functions SDK. I want to create a firestorm trigger and I want to pay attention documents and items collection with some wild card ID. That's what the curly braces around the idea saying whenever a document that matches that pattern is created. My Anonymous function here is going to get involved with a snapshot of that document and some context surrounding the request self better each of the context get the idea of the document region of the snapshot get the raw data. So this is like a JavaScript object representing all the data that was that was in the document that was

created. I'm going to build a reference to a path in a reference to a location in cloud storage where the poster was uploaded. So this is now for those who know plus Georgia g s u r l Smith in the buckets. We're going to generate a URL that's going to go back. Webshop. What I want to do now is the best slide in what we'll do is download that file from stores will download it locally in the instance. It's running cloud in Cloud functions everybody use

the Twitter API to upload that image. Once it's downloaded. Once we have the media ID string for the upload. We're going to turn around build a message. So we're going to Tweet a message. It says take a look at our latest poster that the name of the poster and the you are also the user can click on it and go to the store on the wall types the media ID to it. So you get the you get to see the poster along with the Tweet. So let's go back to the demo and see what happened here. so here we are in Twitter. Let's see if we reload this

page. Do we have some tweets? So these two things actually happened. So we had Unleashed granular web Readiness, which is something I've always wanted to do if we click the link we go to the go to the store and and we see the poster there. So they work so we had a fire star trigger that trigger in response to a new poster being added and it automatically generates social media to drive traffic to our store. So I think that's pretty cool. So I go back to the slides, please. Now, I'm going to just give you a whirlwind tour of how

we generated the images. So this is kind of you can imagine lots of bats jobs where this would work. We I use this amazing fun Library called Frac tactic to generate fractals. It turns out to be one of the great ways to create a lot of random images and I'll just go through the code a little bit. So this is an HDTV function and add fake poster function so that we just curl that URL and I create a little class that makes me the generates a fractal image

one base image in grayscale and then optionally the script takes parameter which can or the lack of a parameter will promise it will tenses a whole bunch of colors and its uses imagemagick that's bill. That ships with five functions on the environment that you've got there. So then creates a random image using the speaker module. So we decided to use the company noun as a topic and we get a verb and adjective so that we put those together into an inspirational message. And then we take the

images that we created earlier and we generate a unique path based on a document ID because then we can make sure that each of these posters has a unique storage path and we upload the poster to a bucket. Of course. This is happening multiple times for each color. And we finally get a download URL to this to be a public URL which is really important for the tweeting and then we put it all together. This is kind of a subset of the data but it just shows you you know where we're putting together a document and we call set on our document reference and that changes the data

in firestorms who are updating both fire. store and storage in this Google Cloud function So and then you end up with Jason Bob like this. What is a couple configuration options that we ended up using time out this fractal, you know two minutes or so. So we extend the time out. I actually increase the memory because I found out that sometimes it ended up using a lot of memory and then that was causing seems to fail occasionally and you can also just your quota. So

it turned out one of the challenges we came up we ran into the last 24 hours is we decided that we wanted to have a nice URL for a friendly shop. So we created the app cuz that's easy and I forgot to turn on billing. Do you get a lot of free executions without even sending a feeling but if you want to make a million images, in fact, if you want to make 40 mm are in a very short amount of time, you'll get a quart of seated so you can see that I got a spike of errors are I also had a where I forgot to do something with my file and I didn't have Twitter's head out. So it's this is the

health tab in the Firebase console for functions. It's really super handy for figuring out what's going on. So the also the local turned out to be one of the reasons that I was having things fail because of memory, I dug actually pointed out in our documentation that I didn't really I hadn't practiced that much with so I didn't realize this it turns out to be handy, but it can also be a gacha normally the file system is read-only you can put whatever you want your functions directory and when you deploy all your

functions, all of those files are available to you you can access them locally, but if you want to write you can write in the temp directory But you want to use platform-independent path so that you can still test locally and on the server even on it, even if you have Windows locally and it's just kind of a good idea. So normally create a temp file like this and then You also need to be careful to know that that local files might be there next time. So they're good for like cashing something. But if you don't need them, you should delete them

because it's an in-memory file system. So it'll cheer up your memory like a super fast and that's great. But you want to clean them up. So you want to make sure that we have for whatever you do. You delete the file unless you really want to keep it there for you know, cuz you're going to reuse it. Next time a cloud functions is server-side code without servers. We love you for that. Most people use it for core app logic or you know, most of the things we talked about today. It's also like our user driving

user growth example, you can easily add features when your apps in motion and that's and then it's great for back-end jobs. That's so that's how we built our app. We use total of 5 Firebase in Cloud features Firebase hosting for Content authentication for login firestore for data and searching cloud storage for all of our images in COD functions to do things on the back end in response to events that happened in our system. This is pretty easy. This is pretty

standard application architecture for when I would consider development of an of a mobile app in 2018. This is I think the way things I will go for a lot of developers if you're building a mobile app or web app. I would encourage you to consider an architecture like this. It's entirely server you only pay for what you use you don't stand up servers you don't log into servers. You don't have passwords. You don't have configuration to just write and deploy your code focus on your app. Logic. That's all you have to do to build an app these days. So that's all the content we have. We will be in

the tent if you want to ask questions. We in the tent across the way over the wooden structure and we'll see you over there soon. Thanks.

Cackle comments for the website

Buy this talk

Access to the talk “Build planetary scale apps with Firebase”
Available
In cart
Free
Free
Free
Free
Free
Free

Access to all the recordings of the event

Get access to all videos “2018 Google I/O”
Available
In cart
Free
Free
Free
Free
Free
Free
Ticket

Interested in topic “IT & Technology”?

You might be interested in videos from this event

September 28, 2018
Moscow
16
166
app store, apps, development, google play, mobile, soft

Similar talks

Jeffrey Posnick
Software Engineer at Google
Available
In cart
Free
Free
Free
Free
Free
Free
Michael Bleigh
Software Engineer at Google
Available
In cart
Free
Free
Free
Free
Free
Free
Mariya Moeva
Product Manager at Google
+ 1 speaker
John Mueller
Software Engineer at Google
+ 1 speaker
Available
In cart
Free
Free
Free
Free
Free
Free

Buy this video

Video

Access to the talk “Build planetary scale apps with Firebase”
Available
In cart
Free
Free
Free
Free
Free
Free

Conference Cast

With ConferenceCast.tv, you get access to our library of the world's best conference talks.

Conference Cast
577 conferences
23209 speakers
8674 hours of content
Sarah Allen
Doug Stevenson