Today we launched TWO new features for the Firebase Realtime Database in beta.
First, we launched a new region for the Realtime Database, in Belgium, in addition to our existing region in the United States. If you would like to store your customer data in Europe, or if you’d like to reduce latency for customers in this part of the world, you can do so today.
Second, we launched a management API for the Realtime Database. With just a REST request you can list, create, update, delete, disable, and re-enable Realtime Database instances.
Once you upgrade your Firebase project to our pay as you go plan, it can contain many Realtime Database instances. You can use multiple database instances to scale beyond the limits of a single database instance, balance load, optimize performance, and more. You can even have a mix of database instances in the United States and Belgium in a single project.
Using the new API, adding another Realtime Database instance to a project is as simple as running curl. You can specify either us-central1 (United States) or europe-west1 (Belgium) for location-id.
curl
us-central1
europe-west1
location-id
curl -H "Content-Type: application/json" \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -X POST \ https://firebasedatabase.googleapis.com/v1beta/projects/{project-number}/locations/{location-id}/instances\?database_id\={my-new-database-id}
Let’s list the instances in our project to see if the new database shows up:
curl -H "Content-Type: application/json" \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ https://firebasedatabase.googleapis.com/v1beta/projects/{project-number}/locations/{location-id}/instances
We get this response, showing both our default Realtime Database instance (with type DEFAULT_DATABASE) and the new one we just created (type USER_DATABASE)
DEFAULT_DATABASE
USER_DATABASE
{ "instances": [ { "name": "projects/{project-number}/locations/{location-id}/instances/{default-database-id}", "project": "projects/{project-number}", "databaseUrl": "https://{default-database-id}.firebaseio.com", "type": "DEFAULT_DATABASE", "state": "ACTIVE" }, { "name": "projects/{project-number}/locations/{location-id}/instances/{my-new-database-id}", "project": "projects/{project-number}", "databaseUrl": "https://{my-new-database-id}.firebaseio.com", "type": "USER_DATABASE", "state": "ACTIVE" } ] }
You can use similar calls to disable, re-enable, and delete instances. Have a look at the documentation to learn more about the commands.
This API is available now, and we have enabled it on existing Firebase projects that have used the Realtime Database in the past month. If you ever use the Google Cloud console, you’ll see the API listed there as well. The Firebase console will soon let you create databases in Belgium as well.
For now, new Firebase projects still have their initial/default database automatically created in the United States. We will change this soon to let you choose its location instead, or you can upgrade to the pay as you go plan today to add more databases. Also, if you have automated the creation of Firebase projects, you’ll need to update it to create the Realtime Database as an explicit step so you can choose the region.
We’re excited about these big advances for the Realtime Database, and we hope you are too!
Hello Firebase Developers!
Dependency management is probably one of your least favorite aspects when it comes to app development - whether that’s managing dependencies for an app that you’re building or for an open source project that you’re maintaining.
That’s why we’ve been working on improving dependency management and versioning for our Firebase iOS SDKs, and putting the spotlight on our Firebase BoM (“Bill of Materials”) for Android.
For both platforms, our goal is to make it easy to know which SDK versions to pick for the products you want to use without any muss or fuss, and move straight on to developing your app. There are few other really important motivating factors too.
Let’s get into the specifics for each platform.
Previously, each Firebase SDK for each product maintained its own version number - for both the SDK and the CocoaPod itself. Whenever an SDK got updated, both the SDK and CocoaPod version numbers would get updated too.
This approach was helpful in that each product could update independently more easily, but we’ve heard your feedback that it also had some drawbacks:
That’s why we’re moving to a unified versioning model for all our Firebase SDKs moving forward.
Every Firebase product will now use the same unified version number for its iOS SDK. At each release of a major or minor update, this version number will update for all iOS SDKs. That means that you can just select the same Firebase SDK version number across all Firebase products you want to use - they’ll be designed to be compatible with each other. For any patch releases, the affected product will be fully compatible with all other products at the same minor version. You can run `pod update` to install the latest patches for all products.
There are also a few more reasons why we think moving to this unified versioning model will help iOS developers in the long run.
We’ve been making more and more of our iOS SDKs open source, which has been great for community engagement, but contributing to them hasn’t always been easy.
In the previous model, whenever a product had a new release, a new individualized tag was created for that product. When it came to integrating multiple Firebase products together, these individualized tags made it difficult to figure out which product's tags matched with each other - both from the perspective of using Firebase to build an app, or to contribute to the open source libraries.
With the unified versioning model, you can directly map your Firebase SDK integrations to a single tag in GitHub for both CocoaPods and the Swift Package Manager. The new model also makes it easier for contributors to understand our release and versioning strategy, and make contributions going forward.
While our current release strategy still revolves around CocoaPods, the versioning system we’re now using closely mirrors the conventions used in the Swift Package Manager as well.
Getting ready for that versioning system was additional motivation to move to this model. In fact, the Swift Package Manager for Firebase is now in beta if you want to give it a try.
Over in the Android world, we’re leveraging Gradle’s support for Android BoMs (or “Bill of Materials”), which provides a way to manage the versions for all the libraries you use by specifying a single BoM version for your app.
Firebase has its own “Firebase Android BoM” which has been around for a while, but we’re putting it back into the spotlight as it’ll be the recommended way to manage your library dependencies going forward. When using the Firebase BoM, all you need to do is set a single Firebase Android version in your app - the BoM’s version - and the BoM will pull in the versions of the libraries mapped to that specific BoM.
When you use the Firebase BoM, you’ll still need to declare which Firebase libraries you want to use in your app, but you will no longer need to specify which versions of those libraries your app will require. Instead, just specify the BoM version you want to use, and the BoM will manage which library version to use. And all these versions will be cross-compatible with each other!
Here's an example build.gradle file that uses the BoM:
dependencies { // Import the Firebase BoM implementation platform('com.google.firebase:firebase-bom:25.11.0') // When using the BoM, don't specify versions for Firebase dependencies implementation 'com.google.firebase:firebase-analytics' implementation 'com.google.firebase:firebase-auth-ktx' implementation 'com.google.firebase:firebase-firestore-ktx' }
If necessary, you can override the library version specified in the BoM by including the desired version in the library's dependency declaration. For example:
dependencies { implementation platform('com.google.firebase:firebase-bom:25.11.0') implementation 'com.google.firebase:firebase-analytics:17.5.0' implementation 'com.google.firebase:firebase-auth-ktx' implementation 'com.google.firebase:firebase-firestore-ktx' }
The goal behind using the Firebase BoM, though, is to avoid needing to do this in your project. Each BoM version is curated to include library versions that all play well together.
The improvements mentioned above are a start to further improvements we plan to make in the near future - from better support for the Swift Package Manager, to providing easier getting started journeys in the Firebase Assistant plugin in Android Studio.
Please stay tuned for more, and as always, reach out to us on the GitHub issue trackers for the Firebase iOS SDK and the Firebase Android SDK to let us know what you think about these updates.
It’s hard to believe it’s already been a year since we launched App Distribution to help you with your internal testing on Android and iOS! Based on all your valuable feedback, we’re excited to share a few updates we made to App Distribution since launch.
Most customers automate their releases with App Distribution to quickly send their latest feature branch builds to their QA teams or release candidate builds to their company. This typically means distributing daily or even multiple times per day, which quickly becomes a long list of releases!
To help make this list more manageable, we added release search in the Firebase App Distribution console and tester apps. Now, it’s easy to search by version or release notes to find, manage, and test the exact release you’re looking to get feedback on.
In-app build alerts notify iOS testers when new builds are available to them, making it easier for testers to install the update right from your test app. In-app build alerts are powered through our lightweight open sourced SDK, which you can quickly integrate into your test app.
To increase download speeds for testers around the world using different devices and network connections, we made improvements to our backend systems that handle uploads and downloads. Now testers have a more reliable experience, with some testers experiencing up to 10 times faster downloads.
We recently released version 2.0 of our fastlane plugin, a major rewrite that stripped away the Firebase CLI as a dependency and makes it easier for you to set up your CI. Now, using App Distribution with fastlane is as easy as running `fastlane add_plugin firebase_app_distribution` to get up and running.
`fastlane add_plugin firebase_app_distribution`
All these improvements made to App Distribution wouldn’t be possible without the active Firebase community. With your help, we’ve been able to add more features to our fastlane plugin and it’s possible to use App Distribution in even more ways. Special shout outs to @gunes_dev, who wrote and maintains our Bitrise Step and @ziebawojtek for all of their contributions and support of the App Distribution GitHub Action.
Your feedback has helped shaped our product and our team loves hearing from developers in the #app-distributions Firebase Community Slack channel - come say hi!
There's a lot more in the works with some exciting features launching soon; you can sign up for our Alpha Program to be eligible to try them out. For developers looking to get started with App Distribution, check out our docs.
Posted by Jason Mill, Flamelink
If you read this blog, chances are you’re a fan of Firebase and the power it gives developers to build incredible products. At Flamelink we’ve used it extensively to build websites, apps and other digital platforms for clients of our agency. Firebase helps take your app from proof of concept to production quickly and easily.
While Firebase backend services like Realtime Database and Cloud Firestore are a great experience for developers, we have struggled to hand over full control to some of our less-technical clients. We found they weren’t comfortable editing data directly, so we were inundated with requests to do small content updates.
We tried many different solutions to make it possible for our clients to update their content - from hard-coding content on the frontend, to syncing Firebase with Google Sheets, and everything in between. We even tried coaching our non-developer clients on how to update content in the Firebase console, but the console was just too powerful for their needs.
So we created Flamelink, a headless Content Management System (CMS) built specifically for Firebase which supports both Cloud Firestore and the Realtime Database. Flamelink allows developers to leverage the power of Firebase and the Google Cloud Platform while giving non-developers an intuitive interface to manage their content.
In this tutorial, we’ll show you how to connect Flamelink to your Firebase project, and quickly get started building an app with Angular, Firebase and Flamelink. As with any Firebase project, you’re not limited to JavaScript, you can use any of the languages that Firebase supports.
A special thanks to our friend Erik Slack for providing this repo of example code to help you get started. You can find him on GitHub, LinkedIn or Twitter.
For the purposes of this tutorial, we’ll be creating a Bedtime Stories app, using long and short story examples to help illustrate how Flamelink can help you manage your content. You can clone the repo by running:
git clone https://github.com/erik-slack/Angular-Flamelink-Firebase.git
In this article, we’ll be covering these steps:
Let’s dive in!
If you haven’t already, go to the Firebase console and sign in. Once you’ve done that, you’ll want to select “Add project” and enter a name for your app.
Once you’ve done this, you’ll be asked a few more questions. For the purposes of this tutorial the choices you make won't matter. After you answer those questions your new Firebase project will be ready!
In this step, we’ll be configuring Firebase Authentication and Security Rules. This is to ensure that you can create, read and update content or files via the Flamelink interface.
First, in the Authentication section of the Firebase console, enable your prefered sign-in methods. You’ll need to configure this to log into your Firebase project via the Flamelink interface.
Then, confirm your authorized domains. Be sure to add the app.flamelink.io domain. This step allows your project’s Firebase Authentication to be used directly by Flamelink.
Next we’ll need to configure the Security Rules. In this tutorial, we’ll be using Cloud Firestore, so look for the Firestore section in the side-panel, create a database if necessary, and then select the Rules tab.
We'll start with the following rules. Note that these rules will allow any user to read / write any content in your database so you’ll need to write more secure rules before launching. These rules are not secure and you should not use them in a real application. For information on how to write more secure rules, check out the documentation.
rules_version = '2'; service cloud.firestore { match /databases/{database}/documents { match /{document=**} { allow read, write: if request.auth.uid != null; } } }
We’ll also need to configure the rules for Cloud Storage for Firebase. Go to the Storage section in the left panel and select the Rules tab once again.
Copy the below code snippet into your Storage Rules:
rules_version = '2'; service firebase.storage { match /b/{bucket}/o { match /{allPaths=**} { allow read, write: if request.auth != null; } match /flamelink/{allPaths=**} { allow read; allow write: if request.auth != null; } } }
Again, these rules are the bare-minimum needed to get a demo working and they are not recommended for production. You must write secure rules before launching your app.
At this point, you'll need to link your Firebase project to a new Flamelink project. You can follow this tutorial video to help you get started.
First, create some schemas. A schema is a form view of your data to easily create your content in a repeatable, structured way. For the bedtime stories example project we used two schemas: shortStory and longStory.
shortStory
longStory
Then, using these schemas, let’s create 5 different Short Stories and 3 Long Stories with whatever filler content you’d like.
Remember, you don’t need to spend too much time on this, just have enough to start building your application. This content is meant to be managed by non-developer content editors and clients.
The sample app in this tutorial was built using nrwl/nx, so there’s a lot going on, but we will only be working with these files.
You’re welcome to explore / modify any other files in the project, get creative!
From the root of the project directory, run either npm install (or yarn install) to install the dependencies.
npm install
yarn install
Because this is an Angular site, we'll use the AngularFire library to quickly and easily add authentication. Let’s create FirebaseService in shared/feature/core. This lets you keep track of auth and allows you to easily sign out. We’ll add FirebaseUI to your login component markup to provide a quick and easy authentication dialog for your users.
FirebaseService
shared/feature/core
<firebase-ui (signInSuccessWithAuthResult)="successCallback($event)" (signInFailure)="errorCallback($event)"> </firebase-ui>
When a use logs in successfully, we want to have it route the logged in user to home.module so add this to your ngOnInit function in the home.component.ts:
home.module
ngOnInit
home.component.ts
this.firebaseService.authState$.subscribe( this.firebaseAuthChangeListener.bind(this));
Next we'll integrate the Flamelink SDK, which is powered by the Firebase SDK, to load content into our app. To do this, create a new service called FlamelinkService in shared/feature/core. This service will be used to subscribe and fetch data when a user is logged in.
Add this to your ngOnInit function in the home.html:
home.html
private firebaseAuthChangeListener(response): void { if (response) { this.loggedIn = true; this.shortStoriesRef = this.flameLinkService.getApp().content .subscribe({ schemaKey: 'shortStory', fields: ['name', 'author', 'text'], callback: (error, data) => { if (error) { return console.error(error); } console.log('data', data); this.shortStories = Object.values(data); this.shortStoriesFacade.loadShortStories(data); } }); this.longStoriesRef = this.flameLinkService.getApp().content .subscribe({ schemaKey: 'longStory', fields: ['name', 'author', 'sections'], callback: (error, data) => { if (error) { return console.error(error); } console.log('data', data); this.longStories = Object.values(data); // this.longStoriesFacade.loadLongStories(data); } }); } else { this.loggedIn = false; if (this.shortStoriesRef) { this.shortStoriesRef(); // unsubscribe from short stories listener } if (this.longStoriesRef) { this.longStoriesRef(); // unsubscribe from long stories listener } } }
Add this to your ngOnInit function in the home.component.ts:
<li *ngFor="let shortStory of shortStories"> <short-story [shortStory]="shortStory" (click)="storyClicked('short', shortStory)"> </short-story> </li>
Remember to update your security rules before launching. This tutorial used insecure security rules to get you up and running as quickly as possible, you will need to update them before releasing your app.
Here are two Flamelink-specific tutorials for writing Security Rules:
We built Flamelink to enhance the Firebase developer experience. Firebase is such a versatile platform, it’s been mind-blowing for us to see how developers are using Firebase and Flamelink to manage content in a diverse range of use cases. We’ve seen Android and iOS apps, PWAs, VR and AR experiences, IoT platforms, websites, blogs, e-commerce/retail platforms, and AI and ML applications that all leverage Firebase and the Google Cloud Platform. So head over to Flamelink.io, sign up for a 14-day free trial and create your first project.
Password-based sign-in remains a popular means of user authentication despite its weaknesses. For example, users frequently forget their passwords, requiring a password reset flow that can create friction for returning users; databases of passwords are routinely shared between bad actors; and, users often reuse insecure passwords across sites, which makes the problem of stolen passwords even worse. On the other hand, the password model of authentication is familiar to users and users expect to see it. For this reason, it's understandable that many developers want to implement some form of password-based sign-in in their apps.
Firebase and Google Cloud Identity Platform provide libraries to make password sign-in easy to implement for your users, but it's important to consider these authentication best practices to enable more secure sign-ins.
Before you launch your app, you should add additional restrictions to your API keys to limit the access they grant. Here are some steps you can take:
Visit our Applying API key restrictions documentation to learn more.
One way to improve security for users who sign in with passwords Is to use password management tools:
If your app deals with sensitive information, the industry best practice, and our recommendation, is to require MFA for user sign-in. This is especially important if your app deals with information such as financial data or medical records. You can add a second factor to most of Firebase Authentication’s sign-in methods, including email address and password, with Google Cloud Identity Platform. To get started, enable Identity Platform in your project, then add MFA to your apps (iOS, Android, Web). Your existing Firebase Authentication code will continue to work after you enable Identity Platform.
If you’re not using MFA, other strong options for user authentication with Firebase are to use one of the social sign-in providers supported by Firebase Authentication such as Google, Facebook, and Apple, or to use email link sign in.
To serve users who don't have or use email addresses, Firebase and Google Cloud Identity Platform provide phone authentication services. This is the best solution for many user bases, but it has its own security caveats: possession of a phone number can be easily transferred between users, and, on devices with multiple user profiles, any user that can receive SMS messages can sign in to an account using the device's phone number. (See the docs for iOS, Android, Web, Unity, C++.)
We recognize the ubiquity of the password model and we will continue working to improve the security of password based sign-in.
