Laravel Aggregates
This episode is for members only

Sign up to access "Laravel Aggregates" right now.

Get started
Already a member? Sign in to continue
Playing
07. Deferred loading of aggregates

Episodes

0%
Your progress
  • Total: 32m
  • Played: 0m
  • Remaining: 32m
Join or sign in to track your progress

Transcript

00:00
To look at aggregates so far, we've been plucking this user out of the database within this root closure. But what happens if you had a URL like this, slash users slash one, and that is the URL
00:14
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
00:34
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
00:59
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
01:21
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,
01:44
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
02:08
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
02:30
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.
02:54
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
03:18
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,
03:39
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
04:02
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
04:27
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
04:50
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
05:13
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.

Episode summary

In this episode, we dive into how to handle loading aggregate data (like counts or sums of related data) when you're using route model binding in Laravel. We kick things off by grabbing a user using route model binding and realize that, while we've got the user, their related aggregate data isn't automatically included. This can be a pain if your page needs, say, the number of posts a user has or the sum of something else.

First, we explore a straightforward (but less efficient) way: re-querying the user and eager loading the aggregates. However, this means extra queries, which isn’t ideal. To make things cleaner, we demo how you can use loadCount or loadSum to defer aggregate loading on an already retrieved model. This gives you the aggregates you want, just a bit later in the request lifecycle.

But what if you want to avoid those extra queries altogether? We go one step further and show you how to override the route model binding logic itself. By customizing the user lookup in your service provider, you can automatically include aggregate data every time a user is fetched via binding—cutting down your query count.

We wrap up by discussing tradeoffs: sometimes you want these aggregates every time, sometimes not. But now you’ve got options: load them later or pull them in right from the start through route binding customization. That's the magic of deferred loading of aggregates!

Episode discussion

No comments, yet. Be the first!