The Firebase team has just released a new update for the Javascript SDK, version 7.21.0 in which a new feature was just added which will save anyone who uses Firestore possibly a lot of money.
In the update, the feature introduces two new where compatible query operators for filtering out data: not-in and !=.
not-in finds documents where a specified field’s value is not in a specified array. != finds documents where a specified field’s value does not equal the specified value. Neither query operator will match documents where the specified field is not present. Filtering in Firestore and Realtime Database has been notoriously limiting. You have to either query exactly what you want using where (say you want to get all items that have an active status). The ability to perform NOT IN clauses inside of traditional databases has been a staple for years, but notably absent in Firebase.
I have been a Firebase user for quite a few years now, since 2016. In that time, I have seen Firebase grow and change as a product. I have also seen the problems people have had with it, as well as the successes.
Googling opinions on Firebase will yield mixed results.
Some are for Firebase and its all-inclusive platform offering features like authentication, a NoSQL database called Firestore, storage, hosting, Firebase Functions (basically AWS Lambda, Google Cloud Functions). Others advise against Firebase because of issues around costs and how the use of resources (reads and writes) are counted.
Recently, while I was building an application on Firebase and implementing Firebase Storage, I realised that I have to always consult old Firebase projects I have built or scour the web for blogs and documentation that explain not only how to do uploads to Firebase Storage but also write rules to protect them.
My use-case is as follows:
Users can create listings A listing can have one or more images An image is uploaded to Firebase Storage in the form of listing-images/userId/filename.extension I only want to allow users to write to this folder if they are that user currently logged in. This folder becomes a bucket for all of the users listing images. Uploading Files const storage = firebase.storage().ref(\`listing-images/${this.auth.currentUser.uid}/${image.name}\`); const upload = storage.put(image); upload.on('state\_changed', // Uploading... (snapshot) => { this.frontImageUploading = true; }, // Error () => { this.frontImageUploading = false; }, // Complete () => { this.frontImageUploading = false; } ); Uploading files with Firebase’ Javascript SDK could not be any easier. You create a reference to where you want to store a file and then you call the put method providing a file to upload.
As much as I love Firebase, especially it’s easy to implement authentication, for some things Firebase can be a bit confusing when you go to implement them.
For Firebase Authentication, sadly, you cannot store any additional information and easily query it for authenticated users. You can leverage custom claims to add little pieces of meta to a user (like roles), but for things such as profile data, you can’t.
Fortunately, there is a solution you can easily implement using Firebase Functions and triggers.
Perhaps one of the most confusing aspects of building a publicly visible Firebase application hosted on GitHub is when you add in your SDK configuration details and commit them you’ll get warnings from a bot called Git Guardian and an email from Google themselves.
I am not sure if everyone gets these, but I do for every publicly visible Firebase application I have on GitHub.
The code in question that triggered these latest warnings for me looked like this:
When it comes to Firebase for newcomers, the first point of confusion in what is quite a simple platform is what should you choose for your database: Firestore or Realtime Database?
As someone who has been using Firebase for quite a few years, there was a time when Firestore never even existed. Initially, it used to just be Realtime Database and that was that. A couple of years ago, Firebase introduced the Firestore database which is the next evolution of databases on Firebase.
I am a huge proponent of Firebase and interestingly, up until recently, I had never used Firebase Storage. Instead, I usually opt for Amazon’s S3 service which I am familiar with. Wanting to keep everything in the one service is appealing to me, so I started to add in file upload functionality in a Firebase Cloud Function.
It was not as straightforward as I would have hoped. I am using Express with Firebase and the Google Cloud NPM package as documented in code examples and numerous tutorials.
Recently whilst I was attempting to port over a TypeScript/Webpack based Aurelia application to work with Aurelia’s newly released server-side rendering functionality, I encountered an annoying error with Firebase Firebase App named '[DEFAULT]' already exists.
Previously, my code looked like this:
import * as firebase from 'firebase'; const config = { apiKey: "", authDomain: "", databaseURL: "", projectId: "", storageBucket: "", messagingSenderId: "" }; export default firebase.initializeApp(config); Because of the way server-side rendering works, it meant that Firebase was being spun up multiple times in my app. This previously wasn’t a problem because of one codebase. To fix it, you just need to alter your default export a little bit.
Firebase Cloud Functions are fantastic, but the URL that you get to run them isn’t so nice. You’ll get given a URL that looks like the following when you create some cloud functions:
https://us-central1-demoapp.cloudfunctions.net/functionName If you are wanting to use Firebase to build an API for your application for example (like I wanted to), then you would probably prefer your URL looks like this:
https://myapp.com/functionName Fortunately, you can. The only downside is you have to use Firebase hosting if you want to be able to alias your functions to your name. If you’re self-hosting your own site somewhere else and using Firebase, then you can’t alias cloud functions.
Admittedly, Google’s developer event IO has grown to be quite interesting the last couple of years. This year (2017) I was excited to see what would be announced in the world of Firebase.
I’ve been using Firebase on and off for the last couple of years. Recently, I’ve found a renewed sense of excitement in using Firebase again (especially after cloud functions were released).
A few of the new features are more mobile-oriented, Firebase likes to focus on mobile developers and applications but it has value for all platforms.