React devs might find this archived course helpful to reference, but this course has been updated! We now recommend you take the Firebase Fundamentals course.
Transcript from the "Cloud Functions Q&A" Lesson
>> Steve Kinney: Yeah.
>> Speaker 1: This may not be pertinent and we can come back to it later. Earlier when futzing around, I had created a version, a collection that only had title content, didn't have any of the user fields. Later went back, saw that there wasn't a method for adding say, the UID or the display name fields via the database ui in the browser.
>> Steve Kinney: Mm-hm.
>> Speaker 1: Is this just too much of a SQL-based paradigm that, there could be plenty of documents. I know like those SQL databases before I've worked in like yeah, you just don't need those, and you don't need to add them in and there are plenty [CROSSTALK]
>> Steve Kinney: That's a great question, it's-
>> Speaker 1: Is that how it would work with-
>> Steve Kinney: It's willy nilly, right?.
>> Speaker 1: Cool, all right.
>> Steve Kinney: There's no necessitated schema. Which opens a series of problems, right? Not problems, let's call them opportunities. Which is on one hand, it's great for when you're prototyping, figuring stuff out, because you can just add new fields to a document.
[00:00:54] It does mean A few things. One is, especially if we were thinking about like on the web, we're kind of pushing out code every time, but if you think about this also in the native application like if you're making React Native application or even iOS or Android. You don't always know that the client, the app, is the most recent version of the app talking to the most recent version of the database.
[00:01:18] So it does require that we code a little bit more defensively. And you'll see some of that as I'm coding today, where it's like there'll probably be documents, I'll probably have to wipe some out, but there are ways to migrate the data. There are ways that we can basically spin up a node process and go through and programmatically add fields if we needed to.
[00:01:35] We'll do with called functions, but you can use the same technique to just call them. When we use the Firebase Admin Library you can just also just run that and do it as well. It does mean that we need to code a little bit defensively and it does mean that yeah, some documents might not have the things that we need so we'd need to figure out a way to migrate them.
[00:01:51] But there is no rule, documents can have whatever, there's no enforced schema. When we get to validations and security rules we can start to make some enforcements that will reject stuff. And we can use called functions to add in things, right? Right now we don't have a, we're just trusting the client when we get to doing a createdAt date.
[00:02:12] It'd be better to have a cloud function do it. Right, so cloud functions can edit the documents after they've been created. And we can always just go ahead and migrate our data and add fields if we needed them. So there's a bunch of options. But to your point, we also need to code defensively cuz we don't really know.
>> Speaker 1: Smaller, possible less pertinent question. In Rails land I would probably set up a cron job to run a rate ask or something. Would setting up a cloud function on a con [CROSSTALK]
>> Steve Kinney: So cloud function technically-
>> Speaker 1: Or would it be, yeah.
>> Steve Kinney: Yes, technically something has to trigger a cloud function.
>> Speaker 1: Yeah.
>> Steve Kinney: So there's a few ways to do it. One is you can have a cron job that triggers [LAUGH] a cloud function, right? But when we learn how to do it just through HTTPS requests, you can theoretically have a cron job that hits that HTTPS endpoint on a regular basis.
[00:03:04] And those services, I think Pingdom will do it where you can just have it regularly ping something. So yeah, that's a thing as well. At SendGrid, we use a lot of AWS lambda functions, and there is a certain amount of cold start time, right, that we have to pay for.
[00:03:20] Pay not in money, but in performance. So what we'll do in a lot of cases, kind of occasionally keep pinging them to keep them alive? Right, cuz once they're warm and running they're already going and they can respond really quickly. But if they get turned off by AWS then that's a performance penalty as they spin back up.
[00:03:37] So we're willing to pay the extra fraction of a penny to occasionally keep them warm. And so you can do stuff like that as well. When we see some of these when we first deploy a cloud function later, we'll see that like it is displeasing how long some of them take at first.
[00:03:52] And then when we do the second thing it's almost instantaneous. So we'll actually get to see some of that at one point as well.