Build An Uptime Monitor with Inertia

Sign in Get started

This episode is for members only

Sign up to access "Build An Uptime Monitor with Inertia" right now.

Already a member? Sign in to continue

Playing

42. Eager loading

Episodes

0%

Your progress

Total: 4h 59m
Played: 0m
Remaining: 4h 59m

Join or sign in to track your progress

01. Introduction

01. Introduction and demo

02. A fresh Inertia project

02. Sites

03. Site and dashboard setup

04. Building the site selector dropdown

05. Making use of API resources

06. Setting the default site

07. Setting up Vue modals

08. Creating a site

03. Endpoints

09. Setting up endpoints

10. Enum endpoint frequencies

11. Creating the endpoint form

12. Storing an endpoint

13. Validating and authorizing endpoint stores

14. Normalizing the endpoint location

15. Displaying endpoints

16. Deleting endpoints

17. Toggling inline editing for endpoints

18. Applying a watcher to the endpoint form

19. Storing endpoint edits

04. Checking endpoints

20. Determining endpoints to check

21. Creating a job to perform a check

22. Making an HTTP request

23. Scheduling checks every second

24. Setting up the check relationship

25. Updating the job

26. Showing the last status

27. Expanded list of checks

28. The response body modal

29. Authorizing the endpoint details

30. Calculating uptime for endpoints

05. Queuing

31. Setting up queues

32. Queuing the endpoint check

06. Email notifications

33. Setting up email in Laravel

34. Site model email notification storage

35. Adding email addresses via the UI

36. Listing and deleting email addresses

07. Downtime notifications

37. Observing when to notify

38. Creating an endpoint down notification

39. Creating an endpoint recovery notification

40. Making the emails a bit friendlier

08. Extras

41. Deleting sites

42. Eager loading

43. Recovery notification bug

44. No sites fix and placeholder

Transcript

00:00

So up until now, we haven't done any eager loading. And I'm guessing the only place we're

00:04

going to need to eager load our relationships in is going to be on the home page. So we're going to go ahead and pull in Laravel debug bar, have a look around, and see what we find.

00:14

Now, eager loading basically will, at the database level, pull in any relationship data you have. So when you're iterating over or accessing relationships within some sort of list, you're not

00:25

going to see multiple queries. Basically, our goal is to reduce the query count down. So when we add more endpoints, which I've done here, and more checks, we don't see lots and lots

00:36

of queries being performed. So I've added a couple more endpoints here. I also have the queue and the scheduler running. So these are consistently performing checks.

00:45

And we have quite a few here. And we're going to go ahead and pull this in and see what we find. So let's go ahead and install Laravel debug bar.

00:52

Let's pull in the composer command for that. And with Laravel debug bar, that's going to be enabled by default. But if you want to, you can go ahead and choose to add in a debug bar-enabled EMV

01:05

value and set this to false to disable it. So if I just give this a refresh, we don't see it. But if we explicitly set this to true and we give the page a refresh, we see it open.

01:17

Now, you can see at the moment we've got 13 queries, which immediately jumps out that we have way too many. Let's just add another endpoint here.

01:25

So what have we got so far? Subjects pro. Let's add something that doesn't exist, like contact. So let's add this in.

01:32

Now, when we give this a refresh, you can see the query count has jumped up. So we know that we have an n plus 1 problem where we're iterating through the list.

01:39

And of course, we are seeing way too many queries. So I'm going to get an email through in a minute because this doesn't actually exist. So you can see the contact went down.

01:48

It's just a page that doesn't exist on here, or in our case, method not allowed because we can't make a GET request to this route. Let's figure out our query count.

01:58

And we're going to do this over on the dashboard controller. So because we've already pulled the site in here, we can't do something like with and then choose the relationships.

02:07

We've got to egoload after this has been pulled in. And we just do that with the load method. So let's look at some of the relationships we're accessing here.

02:15

We can sometimes get a clue from looking at the query. So you can see that what we're doing is for every single iteration of these endpoints, we're accessing the site in here.

02:25

So that's really the first thing that we want to egoload in. So from the site, we want to egoload in the endpoints and the site for the endpoint

02:34

because we're going back from the endpoint and accessing the site. We know that because over in the endpoint resource, we are loading the site in here.

02:42

So what we can actually do in this case, we can say things like this when loaded. We don't need to do this, and I don't tend to do this. But if you wanted to, you could say this when loaded

02:53

and site. What that helps you do is this will not be available if we haven't egoloaded the site in. So I'm not going to do that

03:01

because I prefer to just keep these as they are if I always need them. And we're going to always see that. So let's give that a refresh.

03:08

You can see the query count has jumped down. However, 13 is way too many. And you can see we're making a few sort of duplicate looking requests here.

03:17

So what are these? Well, this is checks here, checks here, and checks here. So we're pretty much doing the same query

03:24

over and over again. So where are we doing this? Well, we're getting a list of checks in here for each endpoint.

03:32

So we can say endpoints.checks. So we want to egoload in every single check from here. We're down to 10 queries. But if we look at this,

03:40

we also have another request to checks. So what's happened? We are egoloading in checks, but remember over on our endpoint,

03:48

we also have the latest check as well. So again, if we open up our endpoint resource, we know that we are always pulling in the latest check, which is that relationship,

04:00

but the singular version, the latest thing. So we're going to go ahead and say endpoints.check, the singular, the latest. Let's go over, give this a refresh.

04:10

We're down to seven queries and there are no duplicates in here. And that is good. So if we come over to one of these routes here

04:18

and give this a refresh, we've only got six queries here, which is absolutely fine because remember for each of these checks,

04:24

we don't have any relationships on these, or at least we're not accessing any of them. We're just basically outputting the data from the table. So that in terms of egoloading is pretty much it.

04:36

We do not want to get to the point where the more endpoints we add in here, the more queries we are performing. And we've solved that with egoloading.

Episode summary

In this episode, we're diving into eager loading and why it's important for our app's performance, especially on the homepage where we list a bunch of endpoints and related data. Up until now, we haven't been using eager loading, which means every time we loop over relationships, we're running lots of unnecessary queries—cue the infamous N+1 problem!

To help us spot where these queries are happening, we bring in Laravel Debugbar. It's a super handy tool that shows us how many database queries are being run on each page load. Right away, we can see the query count is way too high, and as we add more endpoints, it just keeps getting worse.

So, we start fixing this by eager loading the relationships our dashboard relies on. We use the load method to fetch related site, endpoints, and the various checks (plus the latest one) all in one go. Each time we add a relationship to eager load, we refresh the page and watch the query count drop in Debugbar. By the end, we've reduced it to a much more reasonable number, and we've completely solved the issue where more endpoints meant way more queries.

That's pretty much eager loading in a nutshell! We make our app more efficient and set ourselves up so adding more data won't slow things down.

Episode discussion

No comments, yet. Be the first!