QuickHacks #1 - Firebase
Everyone. Peter Tuscinski here and welcome to Quick Hacks, episode 1. It's a brand new bite sized format for hackathon show podcast where we're gonna talk about tools and technologies which will help you build technology products faster. And today, we're talking about Firebase. We're gonna cover Firebase over a few episodes.
Speaker 1:Michal, you're with me here. How are you doing? Hi.
Speaker 2:Hello. Very good. As, well, as I can be in this, heat, but, I'm still trying to survive.
Speaker 1:Alright. Okay. So, it's bite sized, so we're gonna get right into it. What is Firebase? Can you talk a little bit about, you know, a few sentences about Firebase?
Speaker 2:So in a nutshell, Firebase is a suite of tools, which allows you to rapidly prototype, your your app without needing to go to back end. You have databases, you have static hosting, dynamic hosting, and all sorts of cool AI driven products, which you can use directly in your app.
Speaker 1:Okay. So you touched on couple of things. Let's start with databases. It's probably the core of Firebase. There are 2 kinds of databases.
Speaker 1:There is one more coming, which we'll spend the entire episode talking about. Can you shed a little bit of light on those two databases? There is real time database, which is you can probably say it's a legacy kind of database. Right? It's been there from the get go.
Speaker 2:Yeah. This is the the real time database. I think this was the first, the first database which Firebase created. Mhmm. And as as the as as the name says, pretty much, it's it's it's pretty much used to when you need to, propagate changes instantly across your applications.
Speaker 2:However, it's, it's very simple. So you can think of it as just a JSON tree. Right? Mhmm. And there is, the Cloud Firestore, which is a bit more advanced.
Speaker 2:It still it still, propagates your changes, in a in a in a real time manner. However, it's a bit more advanced than the real time database. You can have, custom queries, and it's document based. It's not just a JSON tree. Right.
Speaker 2:They both differ from traditional SQL databases, because they are schema less, and you can enforce the schema using several tools, which we can talk about later. But, the bottom line is, one of them is document based, and the the the other one is pretty much a JSON document.
Speaker 1:Alright. So you can say we have 2 kinds of databases, one real time database. It's JSON tree. It supports offline. Right?
Speaker 1:If you're using Firebase's SDK, on mobile or, web, it it will cache everything in the database and provide offline storage. Querying is limited in real time database. Cloud Firestore is a little bit more advanced. You have it's not a JSON tree. It's a document store.
Speaker 1:Still NoSQL. It will support some queries, but with limitations. So you have, like, probably 30 indexes per query, text searches, a pain at the bottom because you have to engage a third party plug ins to achieve it. It's a little bit more expensive than real time database. Yes.
Speaker 1:But, yeah, there are 2 databases. Next thing I wanna talk about is authentication. I think it's probably the most frequently used feature in my case. I keep recommending Firebase as a almost a go to authentication platform because it's really turnkey. Right?
Speaker 1:So you only all you have to do is create a Firebase project, enable the authentication providers you want to be working with, drop in the SDK that they provide to the client that you're building. And on top of that, you can also use Firebase's UI, which is an open source project, which will basically give you the entire UI for user authentication flow. Right?
Speaker 2:Yeah. Authentication is the core of most applications. It's still, one of the most difficult things. And, there are so many things that can go wrong with it, like, with security, with, with user persistence and and things like that. And Firebase offers you a very wide suite of, authentication, providers.
Speaker 2:All you have all the social providers. You can have phone authentication. And, what what what I particularly like is the anonymous authentication, which means that the user doesn't need to actually authenticate, but they're still provided with a unique identifier, which you can track across a single installation.
Speaker 1:And and then it allows you to like, when user decides to pull a trigger on authentication and giving you more information about themselves, you can bind that anonymous user that they created, like, that you created for them with their actual identity once they decide to log in. Right?
Speaker 2:And you don't lose any content that they created and all of the data that they created, when when they were using the app once they authenticate. And it's seamless. Like, you don't have to do anything to migrate, to transfer. Like, it's just, happening, for you under the hood.
Speaker 1:Oh, yeah. Very cool. There is a whole slew of other things that Firebase offers. There's app hosting like you mentioned. There's cloud functions, which will let you deploy custom code on top of Firebase that is executed on the server side.
Speaker 1:And not only it's a sort of request response kind of, you know, like, very obvious way to call, 3rd party server site code, but it also allows you to attach that custom code to changes in the databases. Right? So you're gonna have triggers that get executed either before, you know, the change happens. So, like, you know, for instance, like, you can perform custom validation on certain fields or when something changes, and you can get that code executed after the fact. So, you know, to propagate something or to fan out some data, because, again, you're working with no non relational databases.
Speaker 1:There is some learning curve and some extra effort that you have to perform in order to, to achieve, you know, things that would otherwise be relatively easy in a relational database. Right? You mentioned remote config, which is another really cool feature of Firebase. You wanna really quickly talk about this? Yeah.
Speaker 1:This is one of
Speaker 2:my favorite features about Firebase. So, basically, remote config allows you, as the name suggests, you can have some configuration values, like the color of the login button to display or specific strings, and there are many data types involved. And, for instance, you can perform AB test with with it, and you can, present one configuration to 1 user and another set of users, and then you can decide, like, which version of the application performs better. And, the changes are are are propagated pretty much instantly. And, well, many products rely on AB tests in order to to validate ideas.
Speaker 2:And, with remote config, these AB tests are a breeze to implement. And what's also worth to mention is, you have all sorts of AI tools which help you make the decision after the test is being made. It's really helpful. I've used it, myself, and, I totally recommend you check it out as well.
Speaker 1:Yeah. And you you touched on a very cool thing, which I wanna double click on because these services are not independent from each other. The the the real power that you will get out of using Firebase is when you're using multiple services in concert together. Right? So an another example of a service that is within Firebase and is really popular is Crashlytics.
Speaker 1:Right? So it basically collects and aggregates crash logs and and poor performance events from your client apps into your, like, one centralized back end. And based on this and working with Crashlytics, you can then segment out a population or a cohort of users who your app crashed on, right, or crashed for rather, and you can give them a discount for an in app purchase, or you can, you know, make you can sweeten the deal basically for them because they experience something, you know, suboptimal. And, again, using these tools in concert will, you know, let you do things remarkably powerful that otherwise would take really long time to build. And these things, all of those services essentially are turnkey and are really quick, even cloud functions.
Speaker 1:Right? Deploying custom, you know, server side code is, you know, is a matter of hours, not days or weeks. Right?
Speaker 2:Yeah. You have to choose a provider. You have to, like, write a Dockerfile. Like, you you know the drill. And, like, all these things are really simple to perform, but they still take time.
Speaker 2:They still take cycles in your brain to choose, like, where to deploy stuff. And here, you get a very nice CLI, which pretty much, does the whole deployment for you. And, you don't have to worry about infrastructure at at all. You just, you just have you just have you just have to worry about implementation of your of your product, implementation of the cloud function, the how how your how your website is gonna look like, how how are you going to use AI models, and how your mobile app is going to look like instead of worrying about the, the infrastructure. That this is
Speaker 1:what I love most about Firebase. Right on. We'll wrap it up with with talking about 2 things. Pricing, there are 2 ways to use Firebase. 1 is free, so it will let you try most of the features.
Speaker 1:There are some limitations as to quotas, and I think you can't make outbound requests with Cloud Functions Yes. When you're on a free plan. Blaze is pay as you go. It's a little bit scary. Right?
Speaker 1:So you get it's it's pretty generous. It of course, it gets expensive as, you know, as you scale up your operations traffic, you know, number of authentications and whatnot. But, again, I think it's, you know, you get your bang bang for the buck because there are so many things that you can, you know, use in a in a very turnkey manner. And the last thing that I wanted to quickly talk about is issues and risks. Is there anything so so out of, like, my experience bucket, I would say, first and foremost, pay as you go.
Speaker 1:Right? So, you know, of course, you have to yes. It's a little bit scary. You have to, like, have limits and alerts and, you know, I personally know a couple of horror stories around Firebase when people basically misconfigured their Firebase and didn't optimize their queries And they woke up one, you know, beautiful day and they had, you know, a couple of $1,000 of ranked up, bills because, again, people have been using their app, you know, overnight in a very heavy manner. The other thing is I remember that that may not be true anymore, but I remember we had some issues with functions cold starting and taking a lot of time to cold start.
Speaker 1:So basic it was a lot of seconds. Right? It wasn't like it wasn't like a typical cold start.
Speaker 2:Also, there are some risks, with vendor lock in. Right? So especially with authentication. We've had multiple scenarios of, clients coming to us and asking us, okay. We have our app hosted here, but we want to migrate all the users there.
Speaker 2:And, we would love, like, 0 downtime, but, you know, we always have to plan for this, like, for for such for such migrations. And, it always takes a bit of time. And, there are always some edge cases, to consider because the devil is always in the details. Like, something may seem very simple upfront, but, once you get, get your hands dirty, like, you start noticing all of those edge cases which, which needs which which need to be considered for, for a seamless experience.
Speaker 1:Of course. But, again, the the only way to get rid of that is build you know, roll your own solution. I mean, even even if you're using Cognito, you are, you know, you're up for a certain amount of vendor lock in. Right? Yep.
Speaker 1:Any other issues with Firebase that you experienced before?
Speaker 2:Apart from those those that you mentioned, I think, the, the only the only issues I encountered is, like, the issues I would encounter from any other NoSQL database. I'm an old time developer, so I was raised on traditional SQL database where I have a schema, validating on a server. So I'm used to that. And, and once once I started using Firebase, like years years ago, like, you had to grasp a new mindset. But, again, like, this is not a Firebase specific problem.
Speaker 2:This is, this is more of a, you know, tech mindset related problem.
Speaker 1:It's funny because you still up to this day, you still, encounter those posts on, like, Stack Overflow about how, like, how do I structure my data? You know? It's it's funny. But, yeah, it takes a little bit of getting used to
Speaker 2:So I've seen this post, like, you know, like, this this is schemaized database. So, So, like, the schema needs to validate it needs to be validated on on the upside. And I don't necessarily agree with that because you have also the tools on the Firebase to actually enforce scheme on the server side, like, you know, triggers like triggers or using, or using the database authentication. So, like, so the user can write only to the specific parts of the database they're authorized to, not any other. So, so there are tools to work with.
Speaker 1:Yeah. And I wanted to say there there are a lot of samples from Firebase or code labs, which will which will guide you through building, you know, like an Instagram clone or Twitter clone and show you how to structure various aspects of the app, like, you know, comments or feeds or whatnot. And one more, I think, interesting caveat or issue to bear in mind, it's not really Firebase specific, but there have been cases where Firebase, database has has been breached because people started working with Firebase database, and, basically, they left it running with yes. With the dev mode. So you start up by, usually by, getting your app and database running, up and running with dev mode, which basically allows everybody to write to everything and read everything.
Speaker 1:And it's buried in the settings. It's, at least it was, a while back. And odds are that, you know, people forget to change that, like, they change, like, they forget to change s three settings, like, right, like s three bucket settings on AWS. And it's scary because, you know, if you don't take care of security, I mean, you know, your entire database is right up there for people to both read and write from. Right?
Speaker 1:So that's a little bit, you know, something that you you really need to keep in in the back of your mind.
Speaker 2:Yeah. That's why it's good to approach these, security rules as you move with your product, not to leave it, to the last moment. It's pretty much like with error handling, you know, like, I've seen many apps which which leave error handling to to the last moment, and then, like, suddenly before releasing, like, you have all of these silently consume errors, which mess up your app and, like, you're, oh my god. Like, there's so much work left to do.
Speaker 1:Yeah. Okay. So that was quick hacks. Number 1, we're gonna do more of these. Stay tuned, and and, yeah, until next time.
Speaker 2:Thank you. Bye bye. Bye.
Creators and Guests
