Sign up to access "Laravel Aggregates" right now.

that you want to use to grab the user, probably with root model binding, and then show all of this information. Well, in this case, how are we going to use with count or with sum? Well, let's take a look at how we would do this now just by switching this route over. We'll keep the root closure, but the same applies if you're using controllers, of course. So let's go ahead

and say users slash, and then let's bring the user in here using root model binding. So we're going to grab the user in here, and we'll just die dump on that user. Okay, so if we just come over and give this a refresh, go over to slash users slash one, we get that user in there. But of course, without any of the aggregates that we need for this page. Now, if you were to look at

it from this point of view, what you would do is relook the user up by their user ID. But that's not efficient. We're going to create an additional query for that. So what we need to do is somehow defer the aggregate of this model that's now coming in via root model binding. Now to do this, what we do is we just get rid of this because we're not looking this user up anymore. So let's

get rid of this too. And we just say user, and then instead of with count, we use load count, much like we would load a relationship in if we were eager loading, and we would use load sum. So that's pretty much going to do exactly the same thing, just a slightly different way of doing things because we've already got the user model in here. If we just give this a refresh, there we go,

we get exactly the same result. Now we do get more queries here, but that is the nature of eager loading. At the point that we hit this root, the user is already looked up and the model is returned to us. So we do create two extra queries here, but we still get the benefit of a lower memory usage because remember, we're not using that collection as almost like a store for all of this information

to then just count the amount of items we have on it. And this isn't a problem just with aggregates, it's with anything that we do in Laravel where we have root model binding. Now there is a way that we can actually get around this, and that is by customizing the logic of how a particular user is looked up. Now this is a really fine line between doing too much when you look a user up

if you don't need this information, but if you really were looking at reducing your query count, let's look at how we would get this back down to one query now. Okay, so to do this, let's head over to our root service provider or our app service provider, it doesn't really matter where we put this, and let's go down to our boot method just here, and we'll do this just at the bottom.

So to do this, we're going to go ahead and use the root facade, we're going to use bind, and we're going to choose the item that we want to customize the resolution logic for, that is of course the user. Let's create a closure in here, and let's go ahead and return and just say user where id, and let's grab the value, considering at the moment we're looking this up

by the user id. So we get the value passed into this closure, let's make sure we pull the user model in, and then we're just going to either say first or first or fail, so we get a 404 if this user can't be found. So that's customized how the user is looked up. We just give this a refresh, nothing really changes because this is that query that we're building up just here,

but what we can now do if we wanted to, and if your goal was to reduce the amount of queries, and you didn't mind having this excess information inside of that every time a user was looked up, we could go ahead and take all of this and use it there. Now we're actually going to return back to what we saw before, so let's go and just pull back everything that we did before with count and

with sum, and let's do this. Now I'm actually going to paste what we changed this to and just comment this out, just so we've got a reference to it there. Okay, so this is what we did before, and this is now what we want to do inside of here. So we want to go ahead and just pull this down, and we want to say with count and with sum. So let's go and just chain that on. So at the

root level now, we're always going to, for any user that is looked up, include all of these counts as we see them, and the sum as well. So let's go over and see the difference now. So I'm going to go ahead and get rid of all of this, or just comment this out. So effectively, we've just got either a root closure or a controller with the user coming in with all of

that kind of aggregate stuff behind the scenes, and if we come over now and give this a refresh, there we go. We get exactly the same as we saw before, because the aggregate stuff is being added at the point where the user is looked up inside of the root level, but we've reduced the queries. So this is absolutely fine to do, of course. It just depends on if you are looking

users up in other places and you don't want all of this in here, but to be honest, it's really up to you. So in this part, we've customized the root logic here to include all of them counts, but we've also looked at where we can load the counts as well and load any other aggregates, and that is deferred loading.