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.