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
24. Setting up the check relationship

Episodes

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

Transcript

00:00
For every check that we perform on an endpoint we of course want to go ahead and store this. So let's start by creating out a model for each of our checks, of course with a migration alongside of that. So let's head over to the create checks table migration and let's think about some of the data that we need to store here.
00:19
Now of course each of the checks that we perform belong to an endpoint, so we'll go ahead and add in a foreign id for the endpoint id here. We'll go ahead and constrain this so it's hooked up to that in the database and really importantly we want to add a on delete cascade so if the endpoint is deleted
00:40
all of the checks get deleted alongside of this. The next thing that we're going to do is create an unsigned integer, so let's choose that and that's going to be the response code or the response status. I'm just going to call it response code and we know that if this check fails for any reason
00:58
we're going to go ahead and store the response body in here and of course we're going to make that nullable because if we have a 200 or any kind of successful response code we're going to go ahead and not store a body so important that is nullable. Okay so for our checks table that's pretty much it so let's go ahead and migrate this out
01:17
and then we're just going to go straight over to the check model and just fill out what we can fill in here or make this completely unguarded so we of course want the response code to be fillable and we want the response body to be fillable as well. While we're in here we'll go ahead and set up the relationship back to the endpoint
01:38
because we know that a check belongs to an endpoint so we may as well add that in here now. Belongs to endpoint and that's done and then we can head over to the endpoint itself and go ahead and add the relationship for our checks so let's go ahead and return very very simple again in terms of the relationships here that this has many checks so we can access them
02:04
as we need now what we're also going to do in here is have the ability to get the last check that was performed now what we of course could do is reference the checks relationship and grab the first one so if we were on an endpoint we could do something like checks and then first but it's a lot more efficient to set up a latest of many relationship in here
02:28
so what we're going to do is create another relationship in here just called check and then we're going to go ahead and say that this has one so it has one check and then what we're going to do is add latest of many so when we access the check relationship just like we normally would as long as we eager load that in we're just going to receive back the latest check that we
02:51
have in terms of the checks that we're storing so that's really really important that we include that so it's a little bit more efficient and to be honest for now that is pretty much it we've got a very simple table out here with the response code and the response body and of course we know what we can do is start to store the data that we get back from the response in this table now

Episode summary

In this episode, we’re setting up the foundation to track every check our application performs on an endpoint. We kick things off by creating a new checks table through a migration, thinking carefully about the data we need to store for each check. This includes things like the response_code (for the status of the check) and an optional response_body (only filled in if something goes wrong with the check).

Next, we make sure that each check record is tied back to the endpoint it belongs to—so we add a foreign key and set up cascade deletes. This simply means that when you remove an endpoint, all its checks automatically get deleted too. Handy!

After rolling out the migration, we jump into the Check model to set up fillable attributes, making it easy to save response data. We also set up the relationship so each check belongs to an endpoint.

On the flip side, in the Endpoint model, we add the inverse relationship—so an endpoint has many checks. There’s also a neat optimization: Instead of always fetching all checks and then picking the right one, we add a special relationship to directly grab the latest check for an endpoint. This is way more efficient and will come in super handy later.

By the end of this episode, you’ll have a checks table ready and all the model relationships set up to easily track and fetch the status of each monitored endpoint.

Episode discussion

No comments, yet. Be the first!