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
39. Creating an endpoint recovery notification
Episodes
01. Introduction
02. Sites
03. Endpoints
09. Setting up endpoints
4m 23s
0%
10. Enum endpoint frequencies
3m 50s
0%
11. Creating the endpoint form
12m 58s
0%
12. Storing an endpoint
7m 21s
0%
13. Validating and authorizing endpoint stores
7m 6s
0%
14. Normalizing the endpoint location
6m 4s
0%
15. Displaying endpoints
6m 22s
0%
16. Deleting endpoints
6m 21s
0%
17. Toggling inline editing for endpoints
5m 12s
0%
18. Applying a watcher to the endpoint form
5m 31s
0%
19. Storing endpoint edits
8m 56s
0%
04. Checking endpoints
20. Determining endpoints to check
2m 57s
0%
21. Creating a job to perform a check
3m 21s
0%
22. Making an HTTP request
3m 39s
0%
23. Scheduling checks every second
4m 27s
0%
24. Setting up the check relationship
3m 14s
0%
25. Updating the job
2m 10s
0%
26. Showing the last status
12m 50s
0%
27. Expanded list of checks
14m 10s
0%
28. The response body modal
2m 49s
0%
29. Authorizing the endpoint details
2m 27s
0%
30. Calculating uptime for endpoints
8m 29s
0%
06. Email notifications
07. Downtime notifications
Transcript
00:00
Now that we are checking for downtime and sending a notification, we're going to move on to check recovery. So we pretty much want exactly the same logic, just the opposite. So let's go ahead and just start out by creating an if statement in here. Again, we're going to split this onto two lines.
00:18
It's going to be very similar to this one. And of course, when something is recovered, it means that it is a successful check. So really, we just want to go ahead and say is successful. Now, we can't obviously just leave it at that, because what's going to happen now is every single successful check is going to produce a notification, which is not what we want. So we're also going to
00:40
say if the previous check, much like we did up here with the previous check checking if it was successful, we're going to say if it wasn't successful. So check previous. And once again, we are going to go ahead and optionally grab that is successful, because of course, we may not have a previous record. So downtime is if the check is not successful, and the previous
01:02
check was successful. And recovery or uptime is when the check was successful and the previous one wasn't successful. We also might want to add on to here, just checking the endpoint checks count is greater than or equal to one because there's no point sending out a recovery if we don't have any checks. So with that done, that is the logic pretty much just the opposite.
01:29
We now just want to implement the event, the listener and the notification to notify everyone. So let's go ahead and do that now. We'll go ahead and create an event first. So PHP artisan make event. And we will say endpoint recovered. And let's go over to our event service provider, copy this, change this to endpoint recovered. And what do we want to do send
01:57
recovered email notifications. So let's comment this out, go ahead and grab this, we can generate these from the command line, but I tend to just go ahead and specify them in straight away and build them out myself. So listener, and send recovered email notifications. Let's bring that back in, pull the namespace in for this, just make sure we pull the namespace in for this.
02:18
And we can now go over to this. Now, there's a lot of copying and pasting here, because we're pretty much doing the same thing. So if we just grab that and come over to the recovered section here, let's go ahead and pop this in handle. And let's go ahead and pull in the notification facade. And the endpoint down notification obviously doesn't apply here.
02:37
This is an endpoint recovery notification. So let's go ahead and create this out. php artisan make notification, endpoint recovered notification, like so. And we can go ahead and switch this out endpoint recovered notification. And let's go into this and just grab the notification that we had before for
03:08
our endpoint down, just the mail message part, that's fine. And let's go ahead and add this in to here. And again, we're just switching things out. So let's say, recovered, and we don't have our endpoint pulled in. So let's pull that in now. And endpoint, and we should pretty much be good. Of course, we just want to switch this out. So
03:31
let's change this to recovered, still want to pass the endpoint down. And let's create the view out to handle this endpoint recovered blade, php. And we'll just copy this paste over and say recovered. Great. Okay, so we should be pretty much good to go. Now, let's just try this out. By making sure that we have cleared everything out. We'll start with a location that works,
03:58
fail it, get the notification, recover it and get the recovery notification. So let's go and just clear everything out of the database, first of all. So let's clear out all these checks. And let's clear out our jobs. And that should be everything we need to do. Let's come over, that's all clean. And I'm actually going to edit this to be a homepage. And let's come over and
04:23
run our queue. And let's run our short schedule. And of course, we're going to start checking, we should see the status rolling. Now, let's go over to our mail client, just delete all of these. And just to keep things simple, I'm going to get rid of one of these email addresses, just so we can keep track of this. So let's go ahead and change this to ABC. And of course,
04:46
if we come over here, we should see an email roll in, telling us that our endpoint has gone down. And there it is. So our endpoints gone down, what's now not going to happen is every single time we check this, it's not going to send another email, we already saw that from the logic that we created earlier. So 10 seconds goes by, we're not going to see another email roll in,
05:07
we're only going to see an email roll in when this endpoint has recovered. So let's recover this in that fake way by just changing the location over. And then we'll just wait for a recovery email to roll in here. Now, it doesn't look like we have received a recovery email. So we're going to have to check out what is going on here. I believe if we come down to our check observer,
05:32
yeah, we didn't actually dispatch the endpoint recovery event, that would help. So let's go ahead and say endpoint recovered. And we should be good. Now, a really important part that we've not mentioned yet about our queue is that when we make a change to code, we need to cancel this off and rerun it, you won't need to do the same for your scheduler. But we're going to rerun our
05:54
queue worker here. And if we just give this a refresh, that has recovered. But we're going to go ahead and go through this whole process again, because obviously, we're a little bit late. So we're going to go ahead and put this down by changing the location over. Of course, we get a went down email, let's go ahead and change this back to technically recover it. And we should see
06:15
once that's recovered, this time around, because we are dispatching that event, an email actually roll in, and it still is not here. So a good way to check this when you have a failed job is you have a failed jobs table. So you can very easily just come in here, grab the exception and expect that. So just to inspect that, I'm going to go ahead and paste into here, and we'll just get the
06:36
output. And you can see here that over in the endpoint recovered event, we don't have a check property, that would help. So really helpful that we can actually inspect that. So let's go over to endpoint recovered, and endpoint recovered event. And of course, we didn't pass the check in. So that would help. But of course, Laravel has dumped that exception in here. So that's great.
07:02
And there we go. So third time lucky, of course, we're going to go ahead and cancel off our event here. We're going to go and rerun it, our queue, sorry, we're going to rerun it. And we're going to go ahead and fail this ABC. And of course, we should see that roll in which we have. And now we're going to go and recover it. And now that we've fixed everything up, hopefully,
07:26
we should see a recovery email finally roll in. And there it is. So this recovered. Now, obviously, the URL is different, because we're just testing this by changing the URL around. So it's a little bit confusing. But you kind of get the idea if we had this as the same URL, and it did actually recover, then of course, it would show the same endpoint here. Okay,
07:48
so that is now the logic to go ahead and notify the user over in our check observer, that the endpoint has recovered. And of course, notice there are not loads of recovered emails rolling in, because our logic prevents that. Let's finish up by just making these emails a little bit more friendly with Laravel's markdown email functionality.
44 episodes•4 hrs 59 mins•1 year ago
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
Hey, I'm the founder of Codecourse!
Comments
No comments, yet. Be the first to leave a comment.