This episode is for members only

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

Get started
Already a member? Sign in to continue
Playing
32. Queuing the endpoint check

Episodes

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

Transcript

00:00
Now that we have queuing set up, we're actually going to go ahead and queue the job that performs the endpoint check. So the first thing that we're going to do is just head over to the database and make sure we clear out all checks here. We're going to see an issue with the way things are
00:12
going to be set up at the moment and we're going to go ahead and fix that in this video. So we want to make sure we have no checks just so we can monitor everything nicely. Okay, so let's hop over to the endpoint check job. So that's the one that makes the HTTP request to that endpoint URL. Now what we're going to do and something that we removed earlier
00:34
is go ahead and implement the should queue interface. Now just by doing this, what's now going to happen is when we dispatch this job, that is now going to be put onto the queue. And if you remember over in our perform checks command here, this is where we're dispatching this. So now that we have configured our queue, when our scheduler dispatches this,
00:55
this will now be put onto the queue. Now we can test this out by going over and running the PHP artisan short schedule run command. And let's just run that through and just see what happens to our jobs table here. This is where all of the jobs are being put onto the queue. These haven't actually been run yet. And what you can see at the moment is these just being consistently and
01:18
constantly put onto our queue. Now I'm going to go ahead and just cancel this command off. The reason that these are being put onto the queue one after another, these are pretty much the same checks happening over and over again, is because let's think about how our endpoint works. We have this next check date. And our console command is going ahead and grabbing all of the
01:39
endpoints where the next check is less than or equal to now. Now the job itself actually updates the next check. So if the next check is never updated, it's always going to be checked every single second. Once the job finishes, the next check date will be incremented. And then it won't be put back onto the queue until the next check date comes around. So really, until we actually
02:04
handle this job on the queue by running queue work, it will just constantly put this onto the queue. So let's go ahead and run both of these commands at the same time to get this working. Well, almost. We're going to see an issue with this. So let's go over to our jobs table and just clear everything out of here. And we're going to go over and first of all start our queue worker. So php artisan
02:25
queue and work. And that's going to run through and listen for jobs that are in the queue. There are none at the moment. Now if we go ahead and run our short scheduler, this is now going to put them jobs onto the queue. And they're going to be processed one after another. So let's go over and just run the short schedule command. You can see them jobs are being put in and slowly processed.
02:45
The checks are coming in. Now already we can see an issue with this. We've got a check here for the endpoint here 8, a check here for endpoint 9, but we've got a duplicate check here for endpoint 9 as well. So even though these two endpoints were only due to be checked once each, we have a duplicate in here. And we're going to see that happen over and over again as our scheduler runs
03:09
and as our jobs are processed in the queue. Now what we're going to do is think about why this might be happening. And to do that, we're going to go straight back over to our console kernel here. So we run the checks perform console command every single second. We do that because we want the date and time here to be very, very precise. We want these to be run exactly when the next check needs
03:34
to be run because we're working with minutes here, potentially say every 30 seconds if you were to set it up to do that. So this is fine and this is what we need because we need this to be checked every second. But what's happening here is over in perform checks, what we're doing is we're grabbing where the next check is less than or equal to now. Now that's absolutely fine. It's going to go ahead
03:52
and find, say, two records. But remember, over in the perform endpoint check job, this is where we are updating the next check. Now if this request takes any longer than one second, which in this case it has, we're not going to see the next check updated until this request is finished. So if this request takes longer than a second, the next check will not have been updated. And what
04:18
that means is the next time this runs, so second two, so the first second it's going to put two onto here, the second second is going to put another one on there because the next check hasn't had time to update. So basically what we want to do here is make sure that we only ever have an endpoint being checked in our queue at once. So we do not want any duplicate checks to happen because this
04:43
is an inevitable part of going ahead and pushing these onto our queue. So how are we going to do this? Well, let's just head back over to the database and give this a refresh. You can see that we've got a few more duplicates here. This is not good. We don't want to send too many requests here. It's going to create duplicate checks and it's going to mess our data up. So I'm going to
05:03
come over and just cancel off our queue, cancel off our scheduler. Let's just clear up the checks table by getting rid of everything in here. And you'll also want to delete any jobs that have hung around in here as well. Okay, so we're going to go back over to our perform endpoint check job. And what we're actually going to do is assign a unique ID to this. So we want this to be unique
05:25
in the database. So to do this, we go ahead and say should be unique for another interface on here and make sure you pull in the namespace for that if it's not already in there. And then we want to assign a unique ID to this using the unique ID method. So unique ID. And let's go ahead and return a unique ID from here. So what's unique about an endpoint that we already
05:47
have passed into this job? Well, just the ID from the database that will do. So let's go ahead and say this endpoint ID. And that's pretty much it. Now what's going to happen is if this job is attempted to be put onto the queue again, and it already has a job in there with that endpoint ID, it's going to fail. Now we need to be really careful here because if you start to queue other
06:07
things within your application that are not endpoints, this ID could be the same as something else. Let's say you are queuing something completely different. And we had an endpoint with an ID of one and a completely different model with an ID of one. That thing would then not be put onto the queue. So what you could do is go ahead and add in maybe endpoint underscore to this to make it
06:29
a little bit unique, more unique to what you have. So let's leave it at that just so we have future proof this. Okay, so now that we've added that unique ID, and we've implemented this should be unique interface, let's go ahead and see how this behaves differently. So I'm going to run the queue worker, going to go ahead and run the schedule. And we're going to head straight over to the
06:48
database and see both of them checks roll in. Already you can see only two of these have been processed, which is exactly what we want. One for this endpoint, and one for this endpoint. I'm going to leave this for a couple of minutes just to see some more checks roll in. And we'll see the difference. Okay, so I've left this run for a few minutes. And as you can see, our checks are
07:07
performing nicely. If you look at the times here as well, they're pretty much going on time. We have a couple of seconds in between, but that's kind of normal because obviously the request takes a little bit of time to actually process and send the HTTP request. But everything is lining up nicely. And our checks are being made as they should.
44 episodes4 hrs 59 mins

Overview

Ready to dive into Inertia? Let's build a real-world app with Laravel, Inertia and Vue! If you're already working with Inertia, you'll pick up some tips and techniques for future projects.

This uptime monitor allows you to create and switch between sites, then add endpoints to monitor with frequency intervals. Using the power of scheduling and queues, it'll automatically alert the email addresses you've added via the UI when an endpoint goes down.

In this course, you'll learn to:

  • Build a real app from scratch with Inertia
  • Work with Laravel queues
  • Perform actions on models at user-defined intervals
  • Work with sub-minute schedules in Laravel
  • Send out channel notifications with Laravel
  • Use API resources to simplify Inertia data
  • Organise apps with events and observers
  • Create modals in Vue
  • Perform inline editing with Inertia forms
Alex Garrett-Smith
Alex Garrett-Smith
Hey, I'm the founder of Codecourse!

Comments

No comments, yet. Be the first to leave a comment.