Instructor: As the next feature in our API,
we have field limiting,
so, basically, in order to allow clients
to choose which fields they want
to get back in the response.
So, for a client, it's always ideal
to receive as little data as possible,
in order to reduce the bandwidth
that is consumed with each request.
And that's, of course, especially true
when we have really data-heavy data sets, right?
And so it's a very nice feature
to allow the API user to only request some of the fields.
So, as the third feature, we will have field limiting.
And, just like before, let me start by showing you
how it's gonna work here in Postman.
So, we're gonna specify a field called fields,
and then the name of the fields
that we actually want to receive.
So let's say we only want the name,
the duration,
the difficulty, and the price, all right.
And so, the implementation will actually be very similar
to what we did before with sorting.
So, if req.query.fields,
then let's actually, again, create a variable
for these fields here because just like before,
Mongodbs, actually requests a string
with the field name separated by spaces, all right?
Now let me actually start by writing out
that part, okay, so, the query itself.
So query is equal to query.select, okay?
And here, for example, it expects a string like,
name then space, duration and a price for example, okay.
And so this way, it will only select
these three field names and send back
the result only containing that, okay?
And actually, this operation of selecting
only certain field names is called projecting okay?
So, let's now go ahead and create basically,
the string, just like we did up there okay.
So we start with req.query.fields,
then we split it by a comma,
and join it with an empty string.
With a space actually, sorry.
So with the space and so that's, then,
gonna produce this exact string with this exact format.
Then here, all we have to do is to use these fields.
Then, just like before, I also want to add a default
so in case the user does not specify the fields field,
okay, so, in that case, we will just
actually remove something, okay?
And let me show that to you first, so down here,
we always have this underscore underscore V,
which is set to zero, and Mongodbs just creates these fields
because it uses them internally.
And we could disable them, but that's not a good practice.
Again, because Mongodbs actually uses them, alright,
but what we can do is to basically
never send them to the client, so we can exclude them.
And the way we do that is to, instead of doing
underscore underscore V like before,
so like we did up here, basically,
we just prefix it with a minus, okay?
And minus is then not including, but excluding.
So what we had before here again,
with the name and duration and price,
that was to include these fields in the response.
But this way, with the minus,
we have everything except the V field here okay?
So we're excluding only this field, alright?
So let's go ahead and test that.
Send it, and let's wait for it and yeah, indeed so,
the ID is by default, always including okay?
So we cannot remove that, but besides that,
we have just the name, duration, difficulty, and price,
okay, and we could, of course, also use that minus
so that exclusion here as well.
So we could have everything, minus the name
and minus the duration, for example.
So let's test that as well.
And so, if you now check it, you will not see the name,
and not see the duration anywhere here.
Right, and now just as a final test,
let's see if our default works as well.
Sending the response and so, now we no longer have
that V variable here set to zero in all the documents.
All right, great, now there's one last thing
that I want to show you which is that
we can also exclude fields right from the schema.
Alright, and that can be very useful,
for example, when we have sensitive data
that should only be used internally.
For example, stuff like passwords
should never be exposed to the client
and so therefore, we can exclude
some fields right in the schema.
So for example, we might not want the user
to see when exactly each tour was created.
For example, tour might already be
kind of old or something and so,
let's say we want to always hide this createdAt field,
alright, so we can go into our schema,
which is in the tour model of course,
and then at createdAt, we simply set
the select property here to false.
And now when we try to get our results,
you see that it's actually no longer there okay?
And so like this, we can basically,
permanently hide this from the output.
Perfect, so one more feature that is actually working now
and so let's now move on right to the next one.