Since we launched the Firebase Admin SDKs for Python and Go last year, many developers have asked for an SDK for .NET. Today, we are happy to announce the general availability of the Firebase Admin SDK for .NET.
Firebase Admin SDKs enable application developers like you to access Firebase from back-end environments. They complement the Firebase client SDKs, which let you access Firebase from web and mobile apps. The Admin SDK for .NET is the fifth SDK variant to join our growing collection of Admin SDK offerings. The SDK currently supports .NET Framework 4.5+ and .NET Standard 1.5+.
The .NET Admin SDK can be initialized with several different types of authorization credentials. The following code snippet shows how to initialize the SDK using a service account credential obtained from the Firebase console:
using FirebaseAdmin; using Google.Apis.Auth.OAuth2; FirebaseApp.Create(new AppOptions() { Credential = GoogleCredential.FromFile("path/to/serviceAccount.json"), });
If you are running your code on Google Cloud Platform, such as Google App Engine or Google Compute Engine, the SDK can auto-discover application default credentials from the environment. In this case you do not have to specify any credentials at initialization:
using FirebaseAdmin; FirebaseApp.Create();
The initial release of the .NET Admin SDK comes with APIs for creating custom tokens and verifying ID tokens for Firebase Authentication. Custom token creation allows you to integrate your own user store or authentication mechanism with Firebase:
using System.Collections.Generic; using FirebaseAdmin.Auth; // Add some custom claims to the token, which will be available on the // ID token after successful sign in. var claims = new Dictionary<string, object>() { { "premium", true }, { "package", "gold" }, }; using FirebaseAdmin.Auth; var customToken = await FirebaseAuth.DefaultInstance.CreateCustomTokenAsync( "some-uid", claims);
ID token verification lets you securely validate the identity of the currently signed in user on your server. You can use this API to build authorized back-end services that integrate with Firebase:
var decoded = await FirebaseAuth.DefaultInstance.VerifyIdTokenAsync(idToken); var uid = decoded.Uid;
To learn more about using the Firebase Admin SDK for .NET, see the Admin SDK setup guide.
Admin SDK for .NET is fully open source. We welcome and encourage our developer community to help us develop this SDK further. Please file bugs and feature requests as GitHub issues, and also feel free to send us pull requests implementing new features and APIs. You can refer to our other Admin SDK implementations for ideas and inspiration.
We look forward to working with you on the Admin SDK for .NET. Happy coding with Firebase!
Firebase Remote Config can be a powerful and easy way to make changes in your app, discover what resonates with your audience, and then quickly revert those changes if needed. Previously, if you wanted to remember what values you used in the past and how they changed over time, you had to keep track of them 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 values at once, this is a major headache.
Today, we are happy to announce that we're adding change history to Remote Config. Finding out who made changes to what values, and reverting back to an earlier set of values is now as simple as a click of a button!
Change History in Remote Config
With change history in Remote Config, Firebase will save 300 versions of a project's Remote Config values for up to 90 days. You'll also be able to see how parameters and conditions have changed over time, who made those changes, when they were made, and how were they made (via the Firebase console or the REST API). And if you ever want to roll back to a previous version, all you have to do is click the rollback button.
Change history is available both on the Firebase Console and via the Remote Config REST API.
Just-eat.com, a European-based food delivery company and a long time Remote Config user, were delighted with change history for Remote Config.
Alberto De Bortoli, Principal iOS Engineer from Just-eat.com "Thanks to change history, no change going to production goes unnoticed anymore. The team now has more confidence and there is no room for ambiguity when it comes to updating Remote Config. We can inspect who across the company made a particular change and rollback to a previous configuration with confidence should there be a need to."
Let's assume Developer Denise wanted to see the previous values of new_search param in her project's Remote Config.
She opens the change history view of her project and sees that her project is currently at Version 37 & that it was created by Mayank Jain. She clicks on the previous version of her project's Remote Config (version 36).
In the change history view, she can see that in the previous version 36, the value of new_search param was built with a 10% users condition - and that Mayank Jain (from her team) had set the value of new_search param to true in version 37 (current live version). Denise can also see that Mayank made that incremental update from the Firebase Console.
Denise wants to roll back Remote Config to version 36, so she clicks the "Rollback to version 36" button.
Remote Config creates a new version 38 which is based on the rollback to version 36.
new_search param in version 38 now has the same conditional value targeting 10% users as was the case in version 36.
Change history for Remote Config is also accessible through the Remote Config REST API.
Following is an excerpt from updates samples to list the last 5 versions using Node.js.
See the full Node.js, Java and Python examples on GitHub and the technical documentation about change history can be found here.
function listLastFiveVersions(accessToken) { const options = { hostname: 'firebaseremoteconfig.googleapis.com', path: '/v1/projects/' + PROJECT_ID + '/remoteConfig' + ':listVersions?pageSize=5', method: 'GET', headers: { 'Authorization': 'Bearer ' + accessToken, }, }; const request = https.request(options, function(resp) { if (resp.statusCode === 200) { console.log('Versions:'); resp.on('data', function(data) { console.log(data.toString()); }); } else { resp.on('data', function(err) { console.log(err.toString()); }); } }); request.on('error', function(err) { console.error('Request for template versions failed.'); console.error(err.toString()); }); request.end(); }
We hope you give change history in Remote Config a try, and as always, we are eager to hear your feedback, so we can make Firebase Remote Config the best way to remotely configure your app. If you're interested in sharing your thoughts, feedback, or opinions on Remote Config or want to see sneak previews of what we've got in the works, please join the Remote Config Discussion Group.
Happy developing!
Crashlytics currently processes more than 3 billion events per day for our developers and distills them into an opinionated and actionable set of issues in our dashboard. We've heard thousands of requests over the years to let you explore further into your crash data, and that's why today we're extremely excited to offer the ability to export your Firebase Crashlytics data into BigQuery for deeper analysis!
With just a few clicks from the Firebase Crashlytics dashboard you can enable daily exports of all raw crash data on a per-app or per-project basis. This includes your stack traces, logs, keys and any other crash data.
The Crashlytics dashboard currently retains data for 90 days. With BigQuery you own the retention and deletion policies, making it much simpler for your team to track year-over-year trends in stability data.
BigQuery also offers the ability to export your data in CSV, JSON, or Avro format. This should help to streamline any GDPR data takeout requests you may receive.
Up until now, exploring your crash reports by custom metadata like Experiment ID or an Analytics breadcrumb has been limited, making it tough to identify which variant in an experiment is least stable or which level in a game has the most crashes. Now, when you export your data to BigQuery, it's easy to run any deep analysis you want, and then visualize your report with Data Studio or any other business system you use.
As an example, say that you set up your Android game so that you log what level a crash occurs with:
Crashlytics.setInt("current_level", 3);
When you export your Crashlytics data to BigQuery, you can then see the distribution of crashes by level with this query:
#standardSQL SELECT COUNT(DISTINCT event_id) AS num_of_crashes, value FROM `projectId.crashlytics.package_name_ANDROID`, UNNEST(custom_keys) WHERE key = "current_level" GROUP BY key, value ORDER BY num_of_crashes DESC
If you are a current Fabric user, you can gain access to BigQuery export and all the other features of Firebase by linking your app in the Fabric dashboard. Check out this link for details and documentation.
We hope this improvement makes it even easier for you to dig into your crash reporting data and efficiently debug your app! As always, if you have any questions, you can find us on Twitter and on Stack Overflow. Happy debugging!
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.
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.
