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

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!