This episode is for members only

Sign up to access "Laravel Performance" right now.

Get started
Already a member? Sign in to continue
Playing
05. Forcing eager loading

Transcript

00:00
We've already seen how we can reduce our query countdown when we're dealing with related models by eager loading.
00:06
But what's the opposite of eager loading? Well, the opposite is called lazy loading. And there's a trick in Laravel that we can use to completely prevent this and actually error
00:16
if we do lazy load. So what I'm going to do is head over to the app service provider here under app and providers. And we're going to go ahead and use the model.
00:26
So under boot, we're going to say model, which is the base eloquent model just here. And we're going to prevent lazy loading. So prevent lazy loading.
00:40
And that's pretty much it. So now what's going to happen is anytime we do not eager load, e.g. we lazy load, we're going to see an error. Now at the moment, luckily we are eager loading.
00:52
But if we head back over to the home controller here and we get rid of this, Laravel is going to detect if we are trying to lazy load. And in that case, if we just give this page a refresh here,
01:04
what we're actually going to see is an attempted lazy load on this model by this relationship. So this gives us a lazy loading violation exception. So a really good place to start when you first set up
01:19
a project would be to prevent lazy loading. Sometimes this can get in the way when you're experimenting. So you can feel free to comment this out and add it in at a later date.
01:29
But it's a really good habit to get into making sure you are eager loading everything in as you go. So you have the benefit of the speed of this, not too many queries.
01:39
Now, one problem with this is if you were to push this code to production and this were to go live, what you're actually going to see is, or rather what your users are going to see is an error here
01:50
if you have forgotten to lazy load something. So a really good practice to get around when you're working with this is adding in a condition. So in here, we want a condition.
02:01
When should this not work? Well, it probably shouldn't work if we are actually in production. So what this is now going to do is if we are in production,
02:10
it's not going to throw this exception. So your users at worst will just see a very slow page. Now we can test this locally by coming up to our EMV here and setting that to production
02:23
and just giving that a refresh. And you can see it just works as it would. So this is how it would look on production. You would have a bunch of queries here.
02:31
Your users would see a slow page, but at least they would be able to see the content. So we're going to leave this in here because it's really important
02:38
that we force ourselves to do this. And of course, we're going to bring back that eager load in here. And now we have a nice snappy page.

Episode summary

In this episode, we're taking a closer look at how to enforce eager loading in our Laravel applications and why you might want to do that. We already know that eager loading related models makes our queries more efficient, but sometimes it's easy to forget to use it, which leads to the less efficient lazy loading.

We'll see a neat Laravel trick where you can tell the framework to completely prevent lazy loading. This means any time you forget to eager load a relationship, Laravel will throw a nice big error—making it much easier to spot and fix accidentally expensive queries during development.

The episode walks through exactly where and how to set this up (spoiler: it's in your AppServiceProvider), and you'll see how just removing one line of eager loading instantly triggers a 'lazy loading violation' exception. This is a great habit to get into for new projects to keep things fast from the beginning.

There's one catch, though: if you push this straight to production, those errors would crash your user's page. So, we'll make things smarter by only preventing lazy loading in development—not production. That way, you get all the dev-time safety, but your users won't see errors if something slips through. Now you can develop with confidence, knowing you're catching inefficient queries early while still keeping your app stable in production.

Episode discussion

No comments, yet. Be the first!