Querying Firestore

[00:00:00]
>> All right, moving on from, we were just doing general reads. If there users, let's read users, if there's expenses, let's read expenses. That's probably not what you're always gonna want. You're gonna wanna narrow it down, you're gonna wanna limit the amount that you get back. So we're going to start focusing on queries.

[00:00:17]
Now queries in FireStore, there are two types. There are simple and composite. We're gonna start by talking about simple queries. And what is important, I'm never sure if I'm jumping ahead of my slides here, but I'll say it as many times, cuz I think it's a really cool spot of FireStore.

[00:00:34]
Is that FireStore, one of the goals of the database design is to ensure that all of your queries run just blazing fast. As a matter of fact, in Firestore, the time it takes to run a query is not proportional to the amount of documents that it looks through.

[00:00:56]
So if you run a query that looks across 60 documents, it can run just as fast as a query that looks across 6 million documents. What usually takes time with Firestore is if, instead of returning back 60 documents, you wanna return back 6,000 documents, because that's just the bandwidth issue at that point.

[00:01:13]
So Firestore is meant to just, whatever queries we support, we support them, because we have a very scalable and fast way of running them. So simple queries in Firestore, they operate on one field. So in this case, we have an example, we were getting an expensive collection. And we're gonna write a query, we say, hey, get all expenses where the cost is greater than 200 and limit that to the first 100 results.

[00:01:46]
So now I know that I will get anywhere between 0 and 100 results, that cost is greater than 200. And while the syntax is a little different, it reads a lot like a SQL query. It's select from expenses where cost is greater than 200, limit, 100. It's just that with a JavaScript API.

[00:02:13]
And with querying, we have lots of different operators. The most basic one is the equals operator. And just because a lot of us here are watching, are JavaScript developers, always make sure you are not using triple equals. We don't do triple equals, we just do double equals, that is a JavaScript specific thing.

[00:02:33]
I can't tell you how many times I've written a bug trying to do a triple equal. So double equals for equality operators. So this says, hey, give me all expenses, limit to the first 100 that are food. And then what's really interesting about equals is that, in FireStore, we can store objects within documents.

[00:02:55]
So in this case, I can actually query based upon the subfields of that object. So if I wanted to say, get all of the expenses, where the user.city is equal to Maputo, which is the capital of Mozambique, then I can limit that to the top 100, and I get all of those back.

[00:03:14]
And I believe you can chain this down to 20 levels deep in an object before it stops letting you do it. But you could say user.city.name.lat.long. You can still run a query even if you have a complex object stored in your document. And something that also works in a really expressive way is with equal equal, we're just checking, hey, is it equal to this value?.

[00:03:42]
But we also can check to see if there's multiple values with the in operator. So in this case, we're saying, let's get all the expenses where the city is in Maputo, Buenos Aires, or Santiago. And so that way, all my results will be restricted to these three. And in operators, you pass in this array, and it can take what I recall correctly, you can provide up to ten values in there to limit from.

[00:04:09]
So this is a really nice way if you can imagine a UI where you have a drop-down list, where you're like, show me the city, that city, this city, that city, and then the query will respond based upon those restrictions. And we also have the ability to do greater than or less than, and I can see already that I have a syntax error, because I don't have my nice ligature.

[00:04:28]
But let's pretend I got that right. And in this case, we're operating against expenses again. We're saying, hey, give me where the cost is greater than 200, but it's less than or greater than or equal to 200, but less than and equal to 210, and limit to the first 100 as well.

[00:04:49]
And just as where I wanna find where things are equal, I can also find where things are not equal. So I can say, give me back the first 30 expenses, where the category of them is not transportation. And similarly where we had the in operator, we have the not-in operator.

[00:05:11]
So I could say, hey, let's get all the expenses from users who are not in all of these cities and then limit to 100. What was this one? I think this is just a, this is, I meant to change the title. This shouldn't say not-in, I believe this should say ordering.

[00:05:33]
So in this case, another interesting thing which you can do with queries is you can specify the ordering. So in this case, I'm saying, where cost is greater than or equal to 200 or where cost is less than or equal to 210. And then I can order by cost, and I can specify an ordering a direction.

[00:05:51]
So by default, it's ascending order, but if I want to do it from a descending value, just do des, and it changes the ordering of that query.