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 Software 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 Software 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:
firebase deploy
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.
Well, I think it's safe to say there's been more news coming out of Cloud Next 2018 than you can shake a stick at. And while your manager is probably asking you to stop shaking sticks at news stories and get back to work, you might still be wondering, "How does all of this affect me, your typical app developer using Cloud Firestore?"
Good question! It turns out we've made some really nice improvements in Cloud Firestore that are either out already, or coming your way soon. Let's go over them together, shall we?
One new feature we've announced is the ability to disable the automatic indexing of a field in your documents. Why would you ever want to do this? Primarily, the issue is that Cloud Firestore will index the value of any field in a document, but if those fields happen to contain maps or arrays, it will then go ahead and recursively index every single value within those objects, too.
In many cases -- like storing a mailing address as a map -- this is exactly what you want, so you can search for documents by city or zip code. But if you're storing a bunch of, say, raw drawing data into a massive array, you definitely don't need those fields indexed. That's going to cost you unnecessary time and storage costs, and runs the risk of bumping up against your "20k indexed fields per document" limit.
So in these situations, we've given you the ability to disable the automatic indexing of those fields. This will stop Cloud Firestore from indexing the value of that field, along with recursive indexing any arrays or maps it might find inside that field. So you can continue to index your "address" field above, while leaving your "big_drawing" field unindexed.
address
big_drawing
Single field index controls also help with that whole "You can't do more than 500 writes per second in a collection where documents have constantly increasing or decreasing values" limit, which is something you could run into if you were, for example, trying to store timestamps in a very large collection. By disabling indexing on that timestamp field, you won't have to worry about this limit, although it does mean you will no longer be able to query that collection by that timestamp.
Many customers have been asking us for the ability to keep their Cloud Firestore data in specific locations around the world. This can be a significant performance boost if you think the majority of your customers are going to be located in a certain part of the world, and it may help you comply with local regulations around how your data is stored.
So we're pleased to announce that we're starting the process of adding new locations to host your Cloud Firestore data. We're going to start with Frankfurt, Germany and South Carolina (in the U.S.), but you can expect to see more locations being added over the next several months.
You should see the "Cloud Firestore location" option when you create a new project in the Firebase console -- this will determine where your Cloud Firestore data is located. Please note that once you've selected a location, it can't be changed later, so choose carefully!
We've also added the ability for you to import and export your Cloud Firestore data. This is useful if you ever want to make backups of your data, it gives you the freedom to migrate your data to another database if you ever wanted to, and it makes it easy for you to copy data between projects. That last feature can come in really handy if you want to migrate data from your production project into your "test", "dev" or "staging" project.
Exports from Cloud Firestore will be stored into your Google Cloud Storage bucket, and from there you can use any number of tools to move your data into other systems. For more details, make sure to check out our documentation.
We're also happy to report that we'll be speeding up the time in which security rules are deployed and made active in your project. Thanks to some serious improvements our engineers have made under the hood, the time it takes for security rules to become active in your project will no longer be measured in minutes. This should make testing security rules in your app a much better experience than before. Look for these security changes to roll out sometime this month.
As we've made improvements on the backend, we've been able to increase some of the limits that were placed on Cloud Firestore while the product is in beta. You can now perform up to 10,000 writes per second per database (up from 2500) and Cloud Firestore supports up to 1 million concurrent connections (up from 100,000) .
Cloud Firestore now runs in two modes -- Native mode and Datastore mode. Native mode is probably what you've been using all this time as a Firebase developer, and it's now available to Google Cloud Customers who want to add Cloud Firestore to their GCP projects.
Datastore mode is a 100% backwards-compatible version for developers who have been using Cloud Datastore up until now. It doesn't contain all of the features of Cloud Firestore (like real-time updates or offline support), but it does add some nice improvements like strong consistency and removes some limits around writes and transactions.
All current Cloud Datastore customers will be seamlessly upgraded to Cloud Firestore in Datastore mode when Cloud Firestore reaches General Availability. For more information, be sure to see this post on the Google Cloud Platform blog.
So there ya go, folks. Lots of fun new features to play with in Cloud Firestore. Give 'em a try and let us know what you think! As always, if you have questions, you can join the Cloud Firestore Google group, or use the google-cloud-firestore tag on Stack Overflow.
Firebase has an impressive feature list for getting your apps up and running quickly. I love that I can go from idea to working app in a matter of hours! But for developers who haven't had much experience with asynchronous programming, it's easy to get bogged down in the details. Heck, I've been working with Firebase for two years and I still find myself pausing to think about how I want to handle asynchronous calls. What will my view look like while waiting to populate data? How should I set up my data class so that it can alert the view controller about updates? After lots of practice and exploring options, I feel like I finally have an answer that works for me.
Now I'm not going to get into the what and why of asynchronous programming with Firebase because Doug Stevenson already addressed this in this great blog post. Instead, I want to get into how to get a function that uses an async callback working the way you want it to in Swift.
Take this example function I have below from this photo app I've created. It queries Cloud Firestore for 10 documents in a collection called "cats". Once the Cat data is downloaded, I want to use it to populate a UITableView with information about the cat photos.
// ViewController.swift var dbRef = Firestore.firestore().collection("cats") var cats = [Cat]() func downloadCats() { // order the posts by timestamp let query = dbRef.order(by: "timestamp", descending: true).limit(to: 10) query.getDocuments { snapshot, error in print(error ?? "No error.") // iterate through the documents and create Cat objects guard let snapshot = snapshot else { return } for doc in snapshot.documents { let cat = Cat(snapshot: doc) self.cats.append(cat) } } print(cats) // 1 what will this print? tableView.reloadData() }
What will be printed at "1"? Since the call to getDocuments is asynchronous, the closure will be run when the download of data is completed sometime in the future. Commands that I write following the closure will be run immediately -- they do not wait for the work in the closure to be complete. So chances are, in the scenario above, that print statement is going to print an empty array. The UITableView will reload data immediately, so any Cat objects that were supposed to populate the view will not appear. That's not the behavior we want. So what can we do?
getDocuments
print
.
UITableView
Cat
One simple option is to move the functionality I want into the closure, like so:
// ViewController.swift func downloadCats() { let query = dbRef.order(by: "timestamp", descending: true).limit(to: 10) query.getDocuments { snapshot, error in print(error ?? "No error.") for doc in snapshot!.documents { let cat = Cat(snapshot: doc) self.cats.append(cat) } print(cats) // 1 what will this print now? tableView.reloadData() } }
What is printed at "1" now? We should now see the full array of Cat objects, and when tableView.reloadData() is called, the UITableView can populate with the data of those Cats, assuming you've set up your UITableViewDataSource for it. This is a viable method for handling data in the closure, but it means you'll have to include this functionality in your UIViewController. As you add more functionality, such as different kinds of queries, Auth, Cloud Storage, and callable Cloud Functions, you'll quickly have a Massive View Controller on your hands.
tableView.reloadData()
UITableViewDataSource
UIViewController
I like to keep this functionality separate from my view controller whenever possible. I can do this by wrapping getDocuments() in a function with a completion handler. If I include a completion handler in this function, I can call completion() when the array of Cats is populated.
getDocuments()
completion()
// CatManager.swift var dbRef = Firestore.firestore().collection("cats") var cats = [Cat]() // function includes an completion handler, marked with @escaping func downloadCats(completion: @escaping () -> Void) { let query = dbRef.order(by: "timestamp", descending: true).limit(to: 10) query.getDocuments { snapshot, error in print(error ?? "No error.") self.cats = [] guard let snapshot = snapshot else { completion() return } for doc in snapshot.documents { let cat = Cat(snapshot: doc) self.cats.append(cat) } completion() } } }
Then inside the view controller, I can call my function like this:
// ViewController.Swift func initializeCats() { activityIndicator.startAnimating() CatManager.sharedInstance.downloadCats() { // Data for UITableView is populated from the CatManager singleton self.tableView.reloadData() self.activityIndicator.stopAnimating() } }
Now I'm controlling the view from the view controller, reloading the tableView and indicating when the activityIndicator should run. The data is being handled in the CatManager class. This does, however, require a singleton, so while it may prevent a massive view controller from developing, singletons come with their own host of issues.
tableView
activityIndicator
CatManager
Instead of passing void in the completion, I can pass some useful values: an array of Cats and an optional error.
error
// CatDownloader.swift // Use instead of CatManager func downloadCats(completion: @escaping ([Cat], Error) -> Void) { var catArray = [Cat]() let query = dbRef.order(by: "timestamp", descending: true).limit(to: 10) query.getDocuments { snapshot, error in if let error = error { print(error) completion(catArray, error) return } for doc in snapshot!.documents { let cat = Cat(snapshot: doc) catArray.append(cat) } completion(catArray, nil) } } }
With this function, since I pass the error in the closure, the view controller can be made aware of an error and display it to the user. Here I made a function called alert() that displays a UIAlertController. I can also create an instance of CatDownloader in the class because I don't need to depend on a single CatManger to keep track of the Cat array.
alert()
CatDownloader
CatManger
// ViewController.swift // create an instance of CatDownloader let catDownloader = CatDownloader() //… func initializeCats() { activityIndicator.startAnimating() catDownloader.downloadCats() { catArray, error in self.activityIndicator.stopAnimating() if let error = error { self.alert(title: "Error", message: error.localizedDescription) return } self.cats = catArray self.tableView.reloadData() } } func alert(title: String, message: String) { let alertController = UIAlertController(title: title, message: message, preferredStyle: .alert) let action = UIAlertAction(title: "OK", style: .default, handler: nil) alertController.addAction(action) navigationController?.present(alertController, animated: true, completion: nil) }
You may want to display a custom error message to the user instead of the error description, but you can see how the closure made it easy to get the info I needed to the right place in my app. You can use this same configuration for other Firebase features that incorporate closures, including the Realtime Database, Authentication, and ML Kit.
And there you have it! Now go forth and write your own functions with closures to help you update your views. What other examples would you like to see? Do you have any cool solutions you've found that you'd like to share? Reach out to me on Twitter at @ThatJenPerson to tell me all about it!
