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.
