‫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.