Scaling your Realtime Database just got a lot easier. We're excited to announce multi-database support in your Firebase Projects!
The Realtime Database is capable of handling a lot of traffic, however it does have its limitations. Scaling past these limits requires "sharding" your data across multiple databases to handle the load. Traditionally, you would need to create another project to get another database. If you need to scale again, you would need to repeat this process.
While this is possible, it's not exactly easy. It's not fun to manage data across multiple projects and authentication is different per project. This generally requires you use Custom Authentication in Firebase Auth, which can be a lot more work. We're happy to say that multi-database solves these problems.
Multi-database allows you to create multiple database instances in a single project. This eliminates managing data across multiple projects. To get started you need to be in the Blaze plan. In the data viewer you can click the triple dot icon to create new database instances:
To access data from a secondary instance you use an absolute URL when creating a database instance.
const app = firebase.initializeApp({ // use your main config databaseUrl: "https://multi-db.firebaseio.com/" }); // This is the default DB. const db1 = app.database(); // Reference the second DB instance. // Keep in mind that you need to upgrade to the latest release before this will work! const db2 = app.database("https://multi-db501c7.firebaseio.com/");
Since these databases are in the same project they share the same Authentication session. Which means no custom server is required.
Important note on SDK versions: Keep in mind that if you have an existing app as of the time of this blog posting, you'll need to upgrade to the latest SDK versions before this will work. (For node admin, you need at least 5.5.0, and inside Cloud Functions you will need at least 0.7.3).
How you shard your database depends on your application. However, there are many useful techniques.
The Master Shard
You can create a "master shard" that contains the mappings to where the data is located in other database shards. This allows you to only request heavier sets of data when needed.
{ "chatrooms": { "general": "room-db-general", "randomchat": "room-db-randomchat", "sweetgifs": "room-db-sweetgifs" } }
Bucketing
You can bucket data per database. This means you can have a users database, a messages database, and a receipts database.
Per customer
If you're developing a multi-tenant service another option is to create a database per customer. This approach ensures that your customers' databases are isolated, in case of load or an outage, it doesn't affect all of your customers.
Each database instance has its own set of security rules. Sharded databases can handle different structures which means you can apply different rules based on that database's purpose. You can manage and test each database's rule set in the console. It's important to note that databases are completely independent. This means you cannot access another database's data in rules evaluation.
We're also excited to announce that Cloud Functions for Firebase supports multi-database as well! You can specify which database you wish to trigger events from:
const functions = require('firebase-functions'); const firebase = require('firebase-admin'); firebase.initializeApp(functions.config().firebase); exports.copymsg = functions.database.instance('room-db-randomchat').ref('/messages').onWrite(event => { const { data } = event; const notificationDb = firebase.database(<your-full-db-url>); return notificationDb.ref(`notifications/${data.key}`).set(data.val()); });
Note that the absolute URL is not required for functions. If no database instance is provided Cloud Functions uses the default database.
const functions = require('firebase-functions'); const firebase = require('firebase-admin'); firebase.initializeApp(functions.config().firebase); // triggers off your default database exports.sanitize = functions.database.ref('/messages').onWrite(event => { // sanitize message here });
Multi-database is an easier way to get to scale with the Realtime Database. We hope you like it, and if you want to learn more check out our documentation. We also have an official support channel, a Slack channel, and we monitor our StackOverflow tags. Don't hesitate to reach out to us!
Firebase Cloud Messaging (FCM) is a cross-platform messaging solution that reliably delivers messages at no cost. FCM sends over 400 billion messages per day. Today we are excited to announce the launch of a new RESTful API, the FCM HTTP v1 API, that makes it safer and easier to send messages to your cross-platform applications. All existing FCM clients can receive messages sent via the new FCM API -- it does not require any changes on the client side.
Security
The new FCM API uses the OAuth2 security model. In the event that an access token becomes public, it can only be used for an hour or so before it expires. Refresh tokens are not transmitted as often and are thus much less likely to be captured.
Sending messages to multiple platforms is possible with the legacy API. However, as you add functionality to messages, sending to multiple platforms becomes difficult. With the new FCM API, sending messages to multiple platforms is very easy.
You can still send simple messages to multiple platforms using the common top level fields. For example, you can send this message informing users about a sale:
{ "message": { "topic":"sale-watchers", "notification": { "title":"Check out this sale!", "body":"All items half off through Friday" } }
When you send a notification like this one to devices subscribed to a topic, you probably want them to be taken to the description of the item. On Android you would compose a message including a "click_action" field indicating the activity to open. On iOS, APNs relies on a "category" indicating the action to take upon clicking, including which view to show.
"click_action"
"category"
Before, since these keys were unique to their respective platforms, developers would have to create two separate messages. Now, we can use platform-specific fields together with common ones in a single message:
{ "message": { "topic":"sale-watchers", "notification": { "title":"Check out this sale!", "body":"All items half off through Friday" }, "android":{ "notification"{ "click_action":"OPEN_ACTIVITY_3" } }, "apns": { "payload": { "aps": { "category": "SALE_CATEGORY" } } } } }
Note: In this case web apps subscribed to the 'sale-watchers' topic will receive a notification message with the defined title and body.
The new FCM API fully supports messaging options available on iOS, Android and Web. Since each platform has its own defined block in the JSON payload, we can easily extend to other platforms as needed. If a future IoT messaging protocol requires a security_key field we could easily support an iot block within the FCM payload.
iot
{ "message": { "topic":"sale-watchers", "notification": { "title":"Check out this sale!", "body":"All items half off through Friday" }, "android":{ "notification"{ "click_action":"OPEN_ACTIVITY_3" } }, "apns": { "payload": { "aps": { "category": "SALE_CATEGORY" } } } "iot": { "security_key": "SECURITY_KEY" } } }
The new FCM API is the more secure, cross platform, future proof way of sending messages to FCM clients. If you are currently using the FCM legacy API, or if you are interested in using FCM to send messages to your apps, give the new FCM API a try. See the FCM guides and reference docs for more.
About FCM
Authorize requests
Build message requests
Migrate from GCM to FCM on Android
Migrate from GCM to FCM on iOS
When the folks at Fabric joined Firebase earlier this year, we aligned around a common mission: provide developers like you with a platform that solves common problems across the app development lifecycle, so you can focus on building an awesome user experience.
One area — among many — where Fabric excelled was in its console and dashboards. We've been hard at work for the last several months, working with them to bring together the best parts of Fabric and Firebase. Today, we're excited to share some improvements to the Firebase console.
We started by redesigning the navigation, to more accurately reflect the way your team works. We've clustered Firebase products into four groups: Develop, Stability, Analytics, and Grow. All of the products that you're used to seeing in the Firebase console are still there; we've simply reorganized them in a way that makes it simpler to navigate between them as you use more products across the Firebase platform.
We've also redesigned the Project Home screen in the Firebase console to bring a few important metrics front and center. Now, when you first open a project in Firebase, you'll see four key metrics: 30-day crash-free user rate, 30-day crashes, daily active users, and monthly active users, along with graphs that displays these trends over time. In research, we found that the vast majority of the time, developers are looking for one of those four metrics, so we made them easily accessible from the Project Home landing page.
Another well-loved Fabric console feature is the Latest Release section. This dashboard gives you all the most important insights from your most recent app release, so you can get a quick snapshot of what's going well and what might need to be rolled back. We've brought this section into the redesigned Firebase Console; you'll find it under the Analytics section of the navigation bar.
Starting today, you'll also see an Analytics dashboard that is organized into simple cards underneath an easy to understand question. Organizing data around jargon like "DAUs" or "retention cohorts" is difficult to navigate, so we've restructured the dashboard around questions you have about your app, like "where are my users engaged?" Or "how well do I retain users?" Our research confirmed that 90% of users preferred this design and we hope you find it helpful too!
Another thing we've learned from our friends at Fabric and heard from all of you is that having information in realtime is critical. Whether you're tracking a new app release or monitoring the status of a bug fix, you need to understand what's happening in your app in realtime, so you can make changes and prioritize work accordingly.
To help with this, we've added realtime data on crashes and active users to a card that you'll see in the new Analytics dashboard, as well as the Latest Release section of the console. This is just the first step and, over time, we plan to make realtime data more prevalent across the rest of the Firebase console.
As always, you can contact us at https://firebase.google.com/support/ with feedback and questions. Happy building!
Since Fabric joined forces with the Firebase team, our collective mission has been to bring the best of our amazing platforms together. Today, we are pleased to announce a major milestone in that mission with the beta launch of Firebase Crashlytics.
Firebase Crashlytics is a powerful, realtime crash reporting tool that will help you track, prioritize, and fix stability issues that erode your app quality. With this launch, Firebase developers can now access the best-in-class crash reporting solution right alongside all the other Firebase products you know and love in one unified console. From this point onwards, Crashlytics will be the primary crash reporter for Firebase, so if you're already using Firebase Crash Reporting, we recommend you upgrade now by clicking on the banner in your Crash Reporting dashboard. New Firebase developers can also start using Crashlytics by first installing Firebase and then clicking on Crashlytics in the left-hand navigation bar.
Here's what you'll get when you upgrade. These benefits and features make Crashlytics a must-have tool for all mobile app developers.
Faster troubleshooting
Crashlytics brings the most critical information regarding your stability to the forefront by grouping crashes based on similarity of stack trace and highlighting their impact. You can easily spot trends with the realtime crash data or, use version filtering to focus in on the specific releases you care about most. We designed the issue overview and the issue detail pages with the end-goal of reducing the time it takes to resolve issues.
On the overview page, your crash-free user rate is prominently displayed so you can gauge which builds are improving in stability.
You'll also notice significance badges. When highlighted, these badges indicate that important information is available for that issue that makes it unusual or stand out from the rest. For example, significance badges will tell you if certain issues only occur on a specific device, OS, or only on jailbroken phones.
Armed with this insight, you can effectively triage issues at a glance and quickly react to urgent problems. Perhaps you'll choose to ignore issues that are only prevalent on jailbroken devices. Maybe you'll choose to first focus on fixing problems that arose because of the latest OS release. Significance badges will help you make smarter decisions with your troubleshooting time.
Custom Keys and Logs
Crashlytics lets you instrument logs and keys, which provide additional information and context on why a crash occurred and what happened leading up to it.
Specifically, you can use logs to gather details on what users were doing right before they encountered a crash (ex. user went to download screen, clicked on download button). You can also use logs to get details on users' actions (ex. image download size). Logs show you a timeline of events that preceded a crash. When a crash occurs, we take the contents of the log and attach it to the crash to help you debug faster.
In some situations, knowing the last state of the user's app is just as important as the order of operations. Keys are key value pairs that record the last known value of something, because they get overwritten as a user navigates through your app. For instance, you can use keys to track the last level a user competed in your gaming app, or the most recent configuration of their custom settings - anything that may be indicative of context that might be relevant for debugging.
Logs and keys are great ways to find clues in the session metadata and retrace your users' steps to reproduce the bug.
Realtime alerting
Stability issues can pop up anytime - even when you're away from your workstation. Not only will new issues appear and be prioritized in realtime in your Crashlytics dashboard, but we'll also send you email notifications when new issues arise, if issues regress, and if issues suddenly increase in impact. That way, you can grab a coffee and step away with the peace of mind that we've got your back. Crashlytics will alert you if anything goes awry with your recently shipped app, so you never miss a critical crash.
Firebase Crashlytics + Cloud Functions for Firebase
In addition to bringing many powerful Crashlytics features into Firebase, we've also gone one step further by starting to integrate Crashlytics with other parts of the platform. Now, you can use Crashlytics data as an event source to trigger Cloud Functions for Firebase to streamline and customize your troubleshooting process. With this integration, you can automate a workflow that routes issues impacting critical app flows (such as your purchase flow) directly to engineers on your team, or to a Slack channel. This way, you can ensure that urgent issues are monitored and escalated properly and promptly.
We're also funneling stability data into various parts of the redesigned Firebase console, so you don't have to dig between different pages to stay on top of stability. Crashlytics data is now visible on your project overview page, Google Analytics for Firebase dashboard, and of course, the latest release section.
This beta launch of Crashlytics is just the beginning of combining the best of Fabric and Firebase. Customers have already started using our platforms together to achieve amazing results. Take Doodle, an app that helps people find the best date and time to meet, as an example. Doodle used Crashlytics and Remote Config to redesign their app and increase retention and engagement.
New Firebase customers can get started with Crashlytics by installing Firebase and clicking on Crashlytics in the left-hand navigation bar, while existing Crash Reporting customers can click on the banner in their dashboard. We'll continue to build out Crashlytics and can't wait to hear your feedback!
If you're already using Crashlytics on Fabric, you're all set for now - no need to migrate yet. We'll share exciting news soon about how your Fabric apps can take advantage of Firebase Crashlytics.
If you're like most app developers, you know that small changes can often make a big difference in the long term success of your app. Whether it's the wording that goes into your "Purchase" button, the order in which dialogs appear in your sign-up flow, or how difficult you've made a particular level of a game, that attention to detail can often make the difference between an app that hits the top charts, or one that languishes.
But how do you know you've made the right changes? You can certainly make some educated guesses, ask friends, or run focus groups. But often, the best way to find out how your users will react to changes within your app is to simply try out those changes and see for yourself. And that's the idea behind A/B testing; it lets you release two (or more!) versions of your app simultaneously among randomly selected users to find out which version truly is more successful at getting the results you want.
And while Firebase Remote Config did allow you to perform some simple A/B testing through its "random percentile" condition, we've gone ahead and added an entirely new experiment layer in Firebase that works with Remote Config and notifications to make it quick and easy to set up and measure sophisticated A/B tests. Let's take a quick tour of how it works!
With the new A/B testing feature, you can create an A/B test that will allow you to play with any combination of values that you can control through Remote Config. Setting up an A/B test allows you to define how the experiment will behave in a number of different ways, including determining how many of your users are involved with the experiment at first…
…how many variants you want to run, and how your app might behave differently for each variant…
...and what the goal of the experiment is.
Different experiments might have different desired goals, and A/B testing supports a number of common outcomes, like increasing overall revenue or retention in your app, reducing the number of crashes, or increasing the occurrence of any event you're measuring in Google Analytics for Firebase, such as finishing your in-app tutorial.
Once you've defined your A/B test, Firebase takes over by delivering these different variations of your app to randomly-selected members of your audience. Firebase will then measure your users' behavior over time, and let you know when an experiment appears to be performing better, based on those goals you've defined earlier. Firebase A/B testing measures these results for you with the same Bayesian statistical models that power Google Optimize, Google's free testing and personalization product for websites.
Fabulous, a motivational app for building better habits, recently made improvements to their app's onboarding flow by using Firebase A/B testing. When the user first starts an app, Fabulous shows them how to complete a habit, presents them with a letter about forming better habits, and then asks them to commit to a simple routine. The team suspected that if they removed a few steps from this onboarding process, more people might complete it.
Some of the screens a typical user encounters when first using Fabulous
So they ran an A/B test where some users didn't see the letter, others didn't see the request to commit to a simple routine, and others skipped both of those steps. The Fabulous team found that by removing both of these steps from the onboarding process, there was a 7% improvement in the rate of users completing the onboarding flow. More importantly, they confirmed that this shorter onboarding experience didn't have any negative impact on their app's retention.
You also have the ability to A/B test your app notification messages through the Firebase Notifications console. You can try out different versions of your notification message and see which ones lead to more users opening up your app from that notification, or which messages lead to users performing some intended goal within your app, like making a purchase.
A/B testing is available in beta to all Firebase developers starting today. If you're excited to get started, you should make sure that your app is wired up to use Remote Config and/or Firebase Cloud Messaging, and that you've updated these libraries to the latest and greatest versions. You can always find out more about A/B testing in our documentation, or check out the A/B Test Like a Pro video series we've been building.
Then, head on over to the Firebase Console and start making your app better — one experiment at a time!
We're delighted to announce the beta launch of Firebase Predictions. With this we are bringing the power of Google's machine learning systems to every developer that uses Firebase. Predictions is a product that can build dynamic user groups based on predicted behavior, determined using a machine learned model, and these user groups can then be targeted using Firebase Cloud Messaging, Remote Config and other technologies. User groups are updated daily to keep your predictions fresh.
Out of the box, there are four predicted groups:
You'll see these three groups right away when you select Predictions in the left nav bar of Firebase Console.
You'll notice that each of these cards has actions that you can take upon them.
Tolerance: The tolerance slider gives you the ability to tolerate low, medium or high risk of false positives. So, with a low tolerance, your population of users will be smaller, but so also will your risk of false positives. Similarly, with a high tolerance, you'll have a larger population of users, but at a risk of some of them being false positives. In the case of 'churn', a false positive would be a user who is predicted to churn, but in fact continues to use your app.
Target Users: This gives you a drop-down on which you can select Remote Config or Notifications for that user group. It also links to some handy guidance for offering in-app incentives.
Selecting Remote Config will take you to a new screen where you can specify the remote config parameter that you want to set up, and then the value for it for that population. So, for example if you've been building a game, and a lot of people have churned and you see from feedback that it's too difficult to play, you could set a remote config variable for the difficulty, so that likely churners could get a lower default value set for them, and thus would have an easier experience playing the game.
Selecting Notifications will take you to the familiar composer for messages to be sent using Firebase Cloud Messaging, but in addition to the usual options for picking target audience, you'll also get the predicted user group pre-populated as a user segment.
This allows you to target notifications at that user group. So, for example, for users at a risk of churning, you could send a notification with an enticement to continue using the app.
Creating your own predictions. You aren't limited to the built-in predictions cards, of course, and can create your own based on custom events that you set up in your app. In this case, you'll see a card that allows you to create a prediction.
And when you select it, you can then create a prediction for when your event will, or will not happen. This helps you identify users who are likely to engage in that conversion event:
So, for example, in the above case, whenever a user levels up in the game, the level_up conversion event is logged. Thus, you could create a prediction for players who may level up, and incentivize them to continue playing.
Then, once you've saved your prediction, over time a card will populate on the Firebase Console in the same way as the built-in ones.
And this card can be used in the same way as the others -- including targeting users with notifications and Remote Config.
Firebase Predictions is a Beta product, and we're continuing to work on it and improve it. If you have any questions or feedback, please reach out -- and for bugs and product suggestions, you can reach us at firebase.google.com/support.
Learn more about Firebase Predictions at firebase.google.com/products/predictions/ or dive straight into our docs right here.
