Build An Uptime Monitor with Inertia
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
05. Making use of API resources

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
6m 33s
0%
02. A fresh Inertia project
6m 7s
0%
02. Sites
03. Site and dashboard setup
8m 59s
0%
04. Building the site selector dropdown
12m 22s
0%
05. Making use of API resources
4m 14s
0%
06. Setting the default site
10m 37s
0%
07. Setting up Vue modals
4m 34s
0%
08. Creating a site
18m 18s
0%
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%
05. Queuing
31. Setting up queues
3m 21s
0%
32. Queuing the endpoint check
7m 26s
0%
06. Email notifications
33. Setting up email in Laravel
5m 8s
0%
34. Site model email notification storage
3m 5s
0%
35. Adding email addresses via the UI
17m 24s
0%
36. Listing and deleting email addresses
7m 14s
0%
07. Downtime notifications
37. Observing when to notify
10m 51s
0%
38. Creating an endpoint down notification
10m 46s
0%
39. Creating an endpoint recovery notification
8m 9s
0%
40. Making the emails a bit friendlier
3m 50s
0%
08. Extras
41. Deleting sites
5m 9s
0%
42. Eager loading
4m 44s
0%
43. Recovery notification bug
2m 31s
0%
44. No sites fix and placeholder
3m 25s
0%

Transcript

00:00
We've got way too much information in here. We don't need a lot of this information like user ID. It's potentially exposing too much information.
00:08
If we add more columns to our database, this is going to be automatically exposed. We really want a nice way to grab the data and expose only the data we want, including relationships.
00:21
So how do we do this? Well, we use API resources. So let's just head back over to our dashboard controller and just see what we're doing here.
00:28
So by using site get, we're actually grabbing a Laravel collection. And when we pass this down to view, it's going to be turned into JSON, basically.
00:37
Now, what we want to do instead is create out a site resource, which will also be turned into JSON, but will only include the columns and data that we need. This is going to make managing the data that you pass down
00:48
to your view templates or view components a lot better. So let's go over and create out an API resource for our site. So we're going to say make resource, and we're going to call this site resource.
01:00
If you've not worked with API resources before, let's just open up that site resource. They're in app HTTP and resources. And let's take a look here.
01:08
So we've got this to array method. Now, all this is going to do is allow us to pass in an array of the data that we want to have this structured. So for example, we could include the ID
01:20
and grab that in some way here. We could include the domain here and grab that in some way here. And that's pretty much all we need. We really, at this point, only need
01:29
the ID of the site and the domain. So how do we do this? Well, let's look at, first of all, how to use this resource. Instead of saying site get, what we're going to do
01:39
is say site resource, and then we're going to say collection. So we can use this for individual sites or a collection of sites, which site get is. So now over in site resource, what we can do
01:51
is say, well, for each item in that collection, I want this ID, which references the model for each iteration, and the domain as well. So let's say this and domain.
02:05
And that's pretty much it. Now, let's go over to our dashboard view file, and let's head up here because sites will not be an array now. This will actually be an object instead.
02:18
Now, let's come over, and if we give this a refresh and have a look here, notice that this is broken. Now, if something like this happens, what I tend to do really, really quickly
02:27
is just dump this out and see what we have. So let's just dump sites out on the page here and see what this gives us. So up here, you can see we've now got this
02:36
wrapped in this data property. Now, you can change that within API resources in general with Laravel, but I tend to keep this structure in here just
02:46
in case I want to reuse the same resource for an actual API endpoint. So what we now need to do is either reference sites.data in here, or in the site selector,
02:57
we now want to iterate through sites.data because the data property now contains the array. I think it makes a lot more sense to pass this down at this level so the site selector is just
03:08
concerned with an array of sites. So now if we come over and give this a refresh, there we go. We have exactly the same thing here, but we now have far less data.
03:19
We can prove that by going over to the site selector and just dumping the site out inside of here just to see what we get. So if we come over here, there we go.
03:28
We've just got the ID and the domain. So much cleaner, only the information we need, and of course, a little bit faster because we're not sitting down too much in this payload.
03:39
OK, so we're going to do the same thing for the site itself. So in here, what we're now going to do is say site resource and make, and we're going to pass that individual object in. Now that we've done that, take a look.
03:53
We've just got the ID and the domain for each of the sites that we're now switching to. So we're going to do this for every single thing that we use within our view templates.
04:04
Create a resource, output only the data we need, and it's much simpler and a little bit safer as well. So we don't include any information in there that we don't want people to see.

Episode summary

In this episode, we take a look at how to use API resources in Laravel to clean up the data we send from our backend to the frontend. Right now, we're sending way too much info—like user IDs and all the columns from our tables—which is not just messy but could potentially expose sensitive data. So, we need a better way to only include the data our frontend actually needs.

We'll walk through how to create a Laravel API resource for the Site model. After generating a resource class, we go in and define exactly which fields to include (just the id and domain, for this example). This has the awesome effect of slimming down our API responses, making them safer and easier to work with.

We then update our controller to use the new resource, and on the frontend, we see that our data is now wrapped inside a data property—useful for APIs but something to keep in mind when consuming this data in templates or components. We fix things up so our views work with the new structure, and confirm that only what we want (site ID and domain) is coming through.

The episode wraps up with a recommendation: do this for every model or response you send to the frontend. That way, you'll always have tidy, secure, and efficient data moving through your app!

Episode discussion

No comments, yet. Be the first!