Do you manage multiple Firebase Hosting sites? Do these sites share a single resource like a Firestore or Realtime database? Do you wish you could manage these sites from one place instead of having to create multiple projects? Do you wish that Firebase Hosting could deploy only the new or modified files? Wish no more! Because it's all here!
Firebase Hosting now allows you to create multiple sites inside of one Firebase project. If your admin site and blog site consume data from a shared Firebase resource, they can now both live in a single project - saving you time and developer resources. You can manage these sites directly in the Firebase Console and deploy via the command line.
Firebase automatically provisions a firebaseapp domain for you, which is the same as your Firebase project name. We currently do not support subdomains on the firebaseapp.com domain, but you can still provision subdomains on your own by connecting a custom domain for your sites. To get started with multiple sites, you'll need to be on the Blaze plan. Once you're on the Blaze plan you'll be able to add multiple sites inside of the Firebase Console.
To help switch between different sites in a single project we introduced a new configuration setup in firebase.json. Make sure you update to the latest version of the Firebase CLI!
firebase.json
{ "hosting": [ { "target": "blog", "public": "blog/dist" }, { "target": "app", "public": "app/dist" } ] }
The "hosting" config can now take in an array of site configurations. A single object still works if you still have just one site. Each configuration has a "target". The CLI uses this target to know what "public" folder to use for deploying assets. Speaking of the CLI! We have a new command for you.
"hosting"
"target"
"public"
To manage switching between multiple sites in one project, we're going to use the target:apply command. This command is a bit like the firebase use --add command except instead of linking the project to the alias, it establishes a link between the site and the target. The applied target can then be used with the firebase deploy and firebase serve commands.
target:apply
firebase use --add
firebase deploy
firebase serve
The firebase use command is helpful for deploying to multiple projects. This is common for those who have a "staging" project versus a "production" project. For managing one site across different environments, we still recommend multiple projects for promoting best practices of each environment having its own set of Firebase resources.
firebase use
However, managing multiple sites is a different problem. The CLI now has to know about multiple sites instead of just one. The CLI must know:
This why we introduced target:apply for Hosting.
firebase target:apply hosting target-name site-name
Let's break down this command.
firebase
hosting
target-name
"blog"
"app"
site-name
Let's say you wanted to deploy your blog using the example firebase.json above:
firebase target:apply hosting blog my-cool-blog firebase deploy --only hosting:blog
In this command, we first identified the target-name of "blog", then associated it with the targeted site "my-cool-blog", and finally deployed to that target. If you don't specify a target in your firebase deploy or firebase serve commands, then all your targets will be deployed, or served locally on different ports, respectively. Note that you only have to define your targets once per project.
If you updated the Firebase CLI recently, you might have noticed that your uploads got a bit faster. You may have also noticed a new .firebase folder in your project. That's because we rolled up a new deployment system that we call Delta Uploads.
.firebase
This new system only processes new, modified, or deleted files. You know, the delta. This means any files that are unchanged aren't uploaded when you run firebase deploy. You may not notice a big improvement in performance if your site is only a few files. However, it will make a huge difference for sites with a large amount of existing unmodified assets.
Check out the official documentation and make sure to update your CLI! Both multi-site and delta uploads features require the latest version of the Firebase CLI. Make sure you're either above or at version 4.2.0 to use these features. Happy deploying!
4.2.0
Notifications, which are messages delivered to a mobile device's home screen, are a great way to bring latent users back into your app. But how do you communicate with users once they're back inside your app? How do you ensure they're interacting with your app in the intended way instead of fumbling between screens without taking meaningful action? How do you guide them through your app experience?
To help you solve those questions, today we're launching Firebase In-App Messaging to help you guide app users who are actively using your app by sending them targeted and contextual messages. Now, you'll be able to communicate with your most valuable users - the ones already interacting with your app - and deepen engagement with them by surfacing relevant information, offers, and tips as they use your app in real-time!
The main purpose of messages sent with In-App Messaging is to "nudge" active users toward key in-app actions (like subscribing, watching a video, completing a level, or buying an item). In-app messages are a guiding light within the app designed to spur conversions, increase session time, and encourage app exploration. In-App Messaging is an essential complement to notifications sent via Firebase Cloud Messaging.
In-app messages appear inside your app, so they should feel like a natural part of your mobile experience. With In-App Messaging, you have the flexibility and control to set up in-app messages in a variety of formats (banners, modal, and image) and customize their look and feel. You can change the color scheme to match your brand, and add visual elements like images. You can also tailor the call-to-action button to match your app's user journeys. And since messages trigger based on Analytics events, if you instrument meaningful events in your app, it's easy to design and test new in-app messages without shipping a new version of your app.
In-app messages are most effective when they are well-targeted and well-timed. In-App Messaging works with Google Analytics for Firebase and Firebase Predictions so you can trigger messages based on user profile data (language, app version, country), current behavior (purchases, screens visited, buttons clicked), and their predicted future behavior (likelihood of spending, risk of churning).
For example, with In-App Messaging and Google Analytics for Firebase, you can send an in-app message to all players using an older version of your game offering a reward if they upgrade their app. Or, you can send an in-app message containing a tip on how to beat a game level when a user fails to complete it.
With In-App Messaging + Firebase Predictions, you can send an in-app message containing a coupon code to users who are unlikely to spend money in your app to entice them to make a purchase.
In-App Messaging also shows you how each in-app messaging campaign is performing. Specifically, it tracks impressions, clicks, and conversions by date so you can understand the success of the campaign and make an informed decision whether or not to re-run it, or alter it, based on the results.
A lot of developers are familiar with notifications, but unsure of when to use in-app messaging. To get the wheels in your head turning, here are some examples of the types of engagement campaigns you could run with In-App Messaging.
These scenarios are just the tip of the iceberg! Whether you want to set up a recurring campaign or send a one-time alert, In-App Messaging supports a variety of use cases.
Get started today by checking out the documentation:
Getting started with Firebase In-App Messaging
We can't wait to see what types of in-app messaging campaigns you run!
At Firebase, our mission is to help mobile app teams succeed, which means having the capabilities to support companies and teams of all sizes and complexity. In the last couple of years, we've matured significantly, from a realtime database to a full mobile app development platform. Firebase is built on top of Google Cloud, so you get all the technical scale, enterprise-grade access control and management, and machine learning strength that underpins many of Google's products. Today, we're excited to share a few new products and features that will help you build better apps, improve your app quality, and grow your business.
Firebase has a number of products to help you engage with your users and grow your business, from machine learning powered targeting with Firebase Predictions, to app optimization without republishing via Remote Config, to re-engaging lapsed users with Cloud Messaging. Today we're adding a new product, Firebase In-App Messaging, to round out the tools available for growing your user base, as well as making improvements to a couple of our existing products.
Notifications are a great way to bring users back into your app. But how do you ensure your users are interacting with your app in the right, intended way instead of fumbling between screens without taking any meaningful action? How do you guide them through your app experience?
Today, we're launching Firebase In-App Messaging to help you guide app users who are actively using your app by sending them targeted and contextual messages. Now, you'll be able to communicate with your most valuable users - the ones already interacting with your app - and deepen engagement with them by surfacing relevant information, offers, and tips as they use your app!
Messages can be customized by format, color, and CTA, allowing you to keep your messages on brand with your app. In-App Messaging is also integrated with Google Analytics for Firebase and Firebase Predictions, making it easy for you to target messages based on user profile data like app version, current behavior like a button click, or predicted future behavior like risk of churning. In-App Messaging is starting to roll out today; check out our documentation for more detail.
The Firebase Cloud Messaging (FCM) console and APIs let you send notifications and data messages to your users on iOS, Android, and web, but understanding how your notifications are performing across all these different platforms is hard. The new FCM reporting dashboard gives teams a central place to view key messaging stats like sends, impressions, and opens, so they can easily understand how their messages are performing. In addition to aggregating all these statistics, the reporting dashboard also gives you insight into your API sends from the console, for the first time.
Developers can use this information to monitor the health of their notification functionality, such as a dip in sends after the release of a new update, as well as use insights on notification sends and opens to improve notification strategy, like monitoring how the title of a notification impacts open rates. The FCM reporting dashboard allows you to filter sends by date, platform (iOS or Android), and type (data message or notification), making it easy to find the data you're looking for.
Previously, if you wanted to check what Remote Config values you've used in the past, you had to keep track manually. In one-person teams this is a hassle, but for large teams, where lots of different developers could be changing the project's Remote Config at once, this was nearly impossible.
Today, we are happy to announce that we're adding change history to Remote Config. Firebase saves 300 versions of a project's Remote Config for up to 90 days. You'll be able to see how parameters and conditions have changed over time and if you ever want to roll back to a previous version, all you have to do is click the rollback button.
We're beginning to roll out change history for Remote Config today and it will be fully available to all projects in a couple of days. Click here to see the technical documentation.
Change history in Remote Config
When the Fabric team joined Firebase last year, we were very excited to learn from their expertise in building tools for crash reporting and debugging. Over the last 18 months, we've made big steps to make Firebase into a platform that you can use to improve your app quality, including bringing Fabric's Crashlytics to Firebase. Today, we're excited to announce a number of improvements to Crashlytics, that help it integrate better with existing tools that developer teams use.
We've heard from you that you rely on a variety of different tools to make your business successful. We want to meet you where you're already working and empower you to use the best tool for the job. That's why we're launching a couple of new integrations for Firebase Crashlytics.
First of all, you'll now be able to export your Crashlytics data from Firebase to BigQuery, allowing you to run your own analysis on deobfuscated crash reports, including any metadata such as custom keys and values, logs, and user IDs. You can then visualize data and view trends with Data Studio or any other business analytics tool you use. You'll also be able to take ownership of your data in BigQuery by setting your own retention and deletion policies.
Secondly, we're launching an integration with Jira Software that allows you to create Jira issues based on crashes reported in Firebase. Combined with the existing integration with Slack, your team can now track the crashes they are working on, with tools they already use. The Jira integration will be rolling out over the coming weeks and if you want to manage your Firebase integrations now, you can visit the settings tab in the console.
Core to Firebase's DNA are a set of products that help developers like you build mobile backend infrastructure quickly and easily. After all, it began with a Realtime Database. We've been working closely with Google Cloud Platform to build a next generation of serverless backend tools, like Cloud Firestore and Cloud Functions, and we're continuing to improve on those products. We're also launching a couple of enhancements to Firebase Hosting that we hope will help you build websites more efficiently.
A few weeks ago at Cloud Next 2018, we introduced a number of improvements to Cloud Firestore and Cloud Functions for Firebase. Cloud Firestore now lets you scale your database up to 10,000 writes per second and 1 million concurrent users to handle any surges in traffic. Cloud Functions is now GA and ready for production use -- with predictable service guaranteed by an SLA. If you're looking to build your infrastructure in certain parts of the world, both Cloud Firestore and Cloud Functions will be supporting new regions in Europe and Asia over the next few months.
Another piece of feedback we've consistently heard is that you don't always have a one-to-one relationship between Firebase projects and hosted websites. Over the next couple weeks, we'll be rolling out an improvement to Firebase Hosting that allows you to host multiple websites within one project.
Additionally, when pushing an update to a site, the Firebase CLI (from v4.1.0) now only uploads the files that have changed between releases. This dramatically speeds up the process, letting you work more efficiently.
The Project Overview page in the console has received a major update, bringing together data from all different parts of Firebase to give you a single view into the health of your app, services and business. In addition to the analytics and crash data that's always been present you can now view performance issues, notification and A/B test status, and the usage and health data for other Firebase services like Functions, Hosting, and Storage, among others.
You'll also notice that the Latest Release section of the console will now have live data. This was one of our top requested improvements to analytics in the console and we're excited to be able to provide it for you.
All of these improvements are beginning to roll out today and will be available to everybody within a couple of weeks.
Thank you, as always, for being a part of the Firebase community. We strive to create a community that is welcoming to developers of all backgrounds and companies of all levels of sophistication. Your feedback and questions are invaluable in shaping the future of Firebase, so, as always, you can find us via any of our support channels.
If you'd like to meet the team in person, please join us at the annual Firebase Summit on October 29th in Prague, Czech Republic for a day full of technical sessions, hands-on instructor-led codelabs, and another round of new updates. Hope to see you there!
Recently, at Cloud Next 2018, we saw some hotly anticipated updates to Cloud Functions, and in particular, the general availability of Cloud Functions for Firebase. As part of that release, there are some additional configurations you can use in your functions when deploying with the Firebase CLI. Let's take a look!
You can now target Node.js 8 as a runtime option (in beta, targeting version 8.11.1). What's in it for you? Most notably, Node.js 8 offers performance improvements with the V8 JavaScript runtime, and the much-desired ability to use ECMAScript 2017 async/await syntax with native JavaScript, without having to transpile. You can read more about async functions here.
You can get started deploying functions to the Node.js 8 runtime by updating the Firebase CLI to at least version 4.0.0. To get the latest:
$ npm install -g firebase-tools@latest $ firebase --version 4.0.0
You'll also need to be using at least version 2.0.1 of the firebase-functions module in your project:
$ npm install firebase-functions@latest
After that, you'll need to make a small change to your project's configuration in package.json. Simply add the following key and value at the top level of the JSON configuration:
"engines": { "node": "8" }
Now, when you run firebase deploy, the CLI will give you some feedback about the deployment runtime in its output:
i functions: updating Node.js 8 function onMessageCreate(us-central1)... i functions: updating Node.js 8 function onMessageDelete(us-central1)...
For those of you using TypeScript to write your functions (and I really think you should!), you can also update your TypeScript configuration in tsconfig.json to target ECMAScript 2017 instead of ES6. Your new configuration will have a compilerOptions block that looks something like the following. Note that target and lib values are now changed to "es2017" instead of "es6".
compilerOptions
target
lib
"compilerOptions": { "target": "es2017", "lib": ["es2017"], "module": "commonjs", ... }
With this, you'll notice that your transpiled TypeScript no longer converts async/await to JavaScript generators, meaning it'll be a bit tighter and faster.
Google Cloud Functions also now allow developers to build with Python, however, the Firebase CLI does not currently support that runtime.
Using the Firebase CLI, you can specify regions per-function to bring your serverless infrastructure closer to your customers or other cloud infrastructure. You can also specify memory allocation and timeout on a per-function basis, tailoring performance to your use cases.
You can do this with the firebase-functions module that you're already using to build your functions, and you can apply these configurations to any type of trigger. Note the new region and runWith methods in this code sample:
region
runWith
const functions = require('firebase-functions'); exports.myHttpFunction = functions // Choose a region other than the default us-central1 .region('europe-west1') // Increased memory, decreased timeout (compared to defaults) .runWith({ memory: '1GB', timeoutSeconds: 120 }) .https .onRequest((req, res) = > { // time and memory intensive tasks res.send('Hello world'); });
Version 2.0.1 or later of the firebase-functions module is required.
If you're just getting started with the Firebase SDKs for Cloud Functions, try following our step-by-step codelab and visiting the documentation. We also have a video tutorial to help get you set up using TypeScript:
We hope you find these new functionality helpful, and we look forward to continue giving you more features to help you build truly serverless apps!
Arrays haven't always been the best data structure for multi-user environments like Cloud Firestore. As Kato describes in the "Arrays are evil" section of his blog post, bad things can happen if you have multiple clients all trying to update or delete array elements at specific indexes. In the past, Cloud Firestore addressed these issues by limiting what you can do with arrays. That means that until now, you could really only "update" arrays by replacing the entire array (no appending or deleting!), and you couldn't perform meaningful queries on arrays, either.
This was problematic for those of you who wanted to use arrays in simple cases like keeping a list of tags or keywords. Previously, we've recommended you try a workaround (some might say, a "hack") of converting your arrays into maps like this:
Well, with our latest improvements to arrays, none of this is necessary! For starters, we've added the ability to query for elements within arrays using the new "array-contains" feature. This means you can keep your elements as an array, and easily query for them without having to resort to the map hack.
array-contains
Even better, you can query for items in arrays that aren't strings, which was a problem with the previous "convert your array into a map" workaround.
You also have the ability to add or remove elements from an array. But in order to avoid some of the issues that can arise in a multi-user environment, you'll be adding them with more of a set-like functionality. So rather than asking to delete an item at index 3, you would ask to remove, for example, all elements of the string "sly" with the arrayRemove operator.
sly
arrayRemove
With the arrayUnion operator, you can append an element to an array, but only if it doesn't exist in the array already.
arrayUnion
Adding "clever" to our array doesn't do anything, because it already exists.
But adding "fuzzy" adds a new element to the array!
These changes also come with some improvements to security rules as well. Now you can create security rules that allow queries based on whether or not a certain element exists inside of an array. So doing things like querying for a list of documents, but only allowing that query if the user is listed inside of the documents' "viewers" array is significantly easier than before.
viewers
This kind of query request is now possible in Cloud Firestore
All of these features should be available with the latest client SDKs, so make sure you update to the latest versions of your libraries, and start having fun with arrays! As always, if you have questions, you can join the Cloud Firestore Google discussion group, or use the google-cloud-firestore tag on Stack Overflow.
