Check out a free preview of the full Firebase with React, v2 course:
The "Wrapping Up" Lesson is part of the full, Firebase with React, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Steve reviews what was covered, as well as the main points to take away from the course.

Get Unlimited Access Now

Transcript from the "Wrapping Up" Lesson

>> Steve Kinney: What we've seen today is, we've got a real-time database that is highly scalable, and a lot more, in a lot of ways, more manageable than the real-time database was. The real-time database is great, I've done a lot of really cool stuff with that. But Cloud Firestore definitely solves a lot, you had to be very nuanced with the real-time database.

[00:00:18] With Cloud Firestore, you're able to kind of structure stuff, in kind of the way you would think about your application, and build documents that start from a UI, backwards. I think a lot of us, as front-end engineers, have gotten APIs. I like to joke at work that I can take any blueprint that the back-end team makes, and build anything off of that.

[00:00:34] I can take any designs that the UI/UX team makes, and build anything based on that. But sometimes, when both of those documents cross my desk at the same time, I can't do anything, right, and that's where it becomes difficult. And so I think being able to kind of think about, first of all, the amount of apps that you could build now, that you probably wouldn't.

[00:00:56] And this is the kind of thing we were talking about the other day, as well. But there's a lot of times when I'm like, I wanna build this app, and I sit down, I'm really excited. And then I remember I have to implement authentication, and then all of the joy leaves my body, and I do literally anything else.

[00:01:12] Now, I flip a switch, I've got some authentication. I think the number of apps that you can build and scale now, cuz this is on Google's infrastructure, right? Effectively, should you design and architect your system well, there's no reason that you couldn't scale this pretty well. You've got file storage, you've got a database, you've got authentication, we've got the ability to run back-end functions, right?

[00:01:39] I think Firebase, for me, is one of the more exciting platforms to build just web services on. And I've had a lot of fun with it, and I plan on having a lot more fun with it in the future. Any large questions that I can answer, for all you?

>> Speaker 1: I mean, we're all excited, we're all, yeah.
>> Steve Kinney: Whoo!
>> Speaker 1: Whoo! When is it bad, when did you, or someone you knew about, regret having gone in the Firebase direction?
>> Steve Kinney: I mean, it's one of those things, you do need to, with any cloud service, right? Here's the thing, the chances of it going down, cuz you messed up, is relatively low.

[00:02:25] Your bad architecture decisions are not gonna take your application down, they're gonna take your bank account down, [LAUGH], right? And yes, that is a happy problem to have, which is, it's gotten so popular! And you can set in, both budget alerts and then also pull-the cord-alerts. But in a lot of cases, it might be slow, it might be expensive, but it will scale, and sometimes that can be a problem, [LAUGH], right?

[00:02:56] Having a back-end that you can pull off the shelf does not, in fact, it puts even more onus on you, the front-end engineer, in this case, to make good architecture decisions, right? We saw with that provider pattern before, that it basically allows us to get the same data in multiple places on our application.

[00:03:14] If we just did that with setState, we would have to do it in all different components, right? Or if we just decide, I'm gonna count all the comments, right, that can get out of control, now, not only on cost, right? But also on the fact of, for a mobile device, right, that is a lot of data that you are sending to that device.

[00:03:37] And that data comes at the cost of, yeah, maybe data plans, but most importantly, battery, right? Which is a great way to get your application in a state I like to call uninstalled, right, and not used, right? So a lot of that performance stuff matters, cuz yeah, we all have fancy phones and stuff like that.

[00:03:56] But all that stuff which was partially a shared responsibility between the back-end engineers in your team and the front-end engineers on your team is now totally on you, right? And a lot of it is a very different set of problems. I like to joke that every back-end engineer thinks that they know front-end because they wrote jQuery form validation one time in 2007.

[00:04:20] And every front-end engineer thinks they know about scalability, cuz they did a join, [LAUGH], in 2011, right? But a lot of this stuff is brand-new to us, right? A lot of it is the learning curve of, how do you structure into a SQL database, is an art, in of itself, that I think for a lot us, we don't necessarily have that muscle totally trained, right?

[00:04:43] It is very different, in a lot of ways, structuring into a SQL database is almost counterintuitive to everything you think about structuring a SQL database, right? Put your data in multiple places is not a thing you do in a SQL database, right? The idea is that you would de-normalize data instead of normalizing it, right, is a totally different thing.

[00:05:02] So you can make very bad choices, cuz I think for a lot of us, we are, by default, predisposed to doing it. Because, yeah, for a MySQL database or something like that, Postgres, what are good choices there are bad choices, right? So it is totally on you to make those choices now.

[00:05:23] On one hand, yeah, you don't have to do as much of the, I never wanna set up a VPS again, personally. I've done it, I don't like it, I don't ever wanna do it again, right? And the idea that I don't have to do it is great, but it also means that this totally kind of different thing is on me to understand.

[00:05:41] And like I said, I think it's still early days, so much of the things that we think are common knowledge in SQL are not, it's just muscle memory for us. So yeah, you can make poor choices, it'll either be expensive choices or just bad user experiences. Insofar the amount of data you're sending over the wire, and stuff along those lines.

[00:06:00] And for a lot of the code that we write, we don't get great logs all the time, right, cuz it's running on somebody else's device, right? We can do emulators and stuff like that, but it's not like, I just looked at this data center, and it's at 99% CPU, or something like that.

[00:06:15] No, just somebody thought, man, this stinks, and took it off their phone, you don't know why, so,
>> Steve Kinney: The other thing is, too, it's like, there is a little bit of vendor lock-in.
>> Speaker 2: That was my first thing, yeah-
>> Steve Kinney: Right-
>> Speaker 2: I'm wondering, how could you make it so it's not so, I mean, it's hard to make it not locked-in, is it?

>> Steve Kinney: Yeah, I mean, good abstractions, right, the idea that we have provider components that are just handing stuff in, rather than writing collection and dock everywhere will go a long way for you, right? So that if you can find the one or two provider components or whatever, thunks in Redux, or whatever you're doing, right?

[00:06:53] And figure it out, giving instruction that most of your application doesn't really care, and I mean, that's true in a back-end thing. Where I work right now, we are rewriting a front-end app, cuz it was so deeply tied to the Rails app, as we move totally to, for us, AWS, right?

[00:07:13] That you couldn't remove the front-end application from the Rails application without significant, it would basically fall out from underneath, right? And so you can get yourself locked into open-source tools, [LAUGH], right? You can get locked, with bad abstractions, you can lock yourself into any back-end, right, yeah?
>> Speaker 2: Well, except that the provider's one provider, so there's no hosting, you can find MySQL, whatever, you can find hosting, yeah.

>> Steve Kinney: Exactly, yeah, so there is a little a bit of that. And there are things like, AWS has Amplify, and stuff along those lines, which is at least built under DynamoDB databases. That if you decide you don't like that abstraction, you can just use the Dynamo databases, right, and stuff like that.

[00:07:54] And I think it's getting less so, Firebase was a lot more of a black box two years ago. I think, at that point, it was totally like closed-source, I think a lot more of it is open now. And as it moves, Google acquired it, I wanna say two years ago, maybe three.

[00:08:10] And it's moving on to more of a kind of standard Google infrastructure, as well. I think Cloud Firestore is somwhat based on Cloud Datastore, which is just a GCP database, as well. So it is less true, with Firestore, less true than it was with the real-time database, but yeah, that's the thing too, right?

[00:08:33] But like I said, I'm tied to a Rails app right now, so, [LAUGH], anything's possible with the wrong abstractions, [LAUGH], yeah. Cool, thank you so much for coming and joining me today.
>> Speaker 1: [APPLAUSE]