In this next episode, we'll switch over and figure out how we can instead make an AJAX request to fetch our data. So for example, I'm going to go to my welcome page, and before, we were manually passing in the keys and the values, but what if the graph can do that itself? Instead, maybe it accepts a URL endpoint, and that should refer to our API endpoint that we're requesting. So for example, maybe it's api/revenue. Okay, well, before we make that work, let's switch over to my routes file, and I'm going to create a new one, Route::get('api/revenue'), and now, yeah, we can return this query right here.

to create a new one, route get API/revenue, and now, yeah, we can return this query right here. All right, so let's go back. We've now added a new URL property, which means we need to go back and tweak our graph. This time, we're deciding, yeah, you'll never pass in the keys and values, you'll always use the AJAX approach. So I can replace this with URL. Next, down here, we can no longer immediately render the graph because we haven't yet fetched and received the data. So how are we going to do this?

and received the data. So how are we going to do this? Well, if you have something like jQuery installed, which lots of people do, you could do jQuery.get or jQuery.ajax. If you're using maybe the fetch API, this is kind of brand new, so be careful. Not every browser supports it yet, but then you could do fetch API /revenue, and then get the JSON response and proceed. But in our case, we are using Vue, so why don't we pull in the Vue resource extension like this, npm install vue-resource. And we have that.

like this, npm install vue-resource. And we have that. So let's hold off on this for the time being, go back to our main entry point, main.js, and right up here, we will import vue-resource from vue-resource. And then finally, we'll say Vue.use(vue-resource). This is sort of like how we register a Vue plugin with Vue. Okay, so now check it out. Here's what I can do. I can say this.$http.get, and now don't forget, we can reference this custom property here. So we'll essentially be doing this.$http.get('/api/revenue').

I can say this HTTP GET, and now don't forget, we can reference this custom property here. So we'll essentially be doing this HTTP GET API/revenue. But I will reference the URL. Next, what do we do after that? So once we have our promise and everything has been resolved, we will then receive the response and then render the graph. So now I can take all of this stuff and insert it here. Now actually, a quick note on this. Because we are using the fat arrow within here, this is still going to refer to what it did before.

Because we are using the fat arrow within here, this is still going to refer to what it did before. But if instead you're passing a function, well, yeah, remember, at that point, the this keyword no longer refers to what it used to. So you would then have to either do .find this on the function call or do one of those things where you say var context equals this. But yeah, that's a big benefit to using the fat arrow with ES6. Now one final thing. We have the response. So we can fetch the data.

We have the response. So we can fetch the data. In fact, let me just show you by doing response.data. Okay, so real quick, let's compile all of that down. And we know we'll get some issues here with this.keys and this.values. But it's fine for now. So if we load this in the browser, here's our object. And we have the same data as we did before. But now we're making an AJAX request. So yeah, real quick, in this case, we're still doing it where we want the keys and the values.

But yeah, you get the idea. All right, so let's go back. There's the data. So if I want the keys, I could say Object.keys(response.data). Now for values, unfortunately, it's in the spec that you can do Object.values(response.data). But a lot of browsers don't support it just yet. It's not part of ES2015. I think it's ES2017 or something. So you will eventually be able to do that. But right now, you would have to do something like a typical map.

So you will eventually be able to do that. But right now, you would have to do something like a typical map. So for example, Object.keys response.data, and then map over that. And for each one, that will correspond to the key itself. And we will just return response.data[key]. And yeah, I think that should do the trick. So why don't we clean this up just a bit? Why don't we say const data equals response.data. And then I can reference that here, here, and then this one as well. Okay, so do you see what we're doing here?

And if I come back, let's give this a refresh. And there we go. So we can see what we had before. And if we bring back Chrome DevTools and open up View DevTools, there we go. So notice you're no longer storing the key and the value. We can put that on the graph if you want, but it may not be necessary at all. So we're only storing these two properties at this point. So let me show you how this works. If we were now to go back and we set something else up, like route, get, API, something else. And maybe we just return a list of ages.

If we were now to go back and we set something else up, like route, get, API, something else. And maybe we just return a list of ages. So we could do myself, I'm 31, John will be 15, Sarah will be 50, and Luke will be 60. Okay, well, now let's load that data. We come back, API/something. And if we come back and refresh, we can now see that plotted on the page. Pretty cool. But yeah, of course, you would want to make sure that the data you return from your API lines up with how you parse it from your graph.

And this isn't necessarily related to the charting library whatsoever. So for example, let's go back to welcome and bring that back to our original API request. Well, of course, presumably, only administrators should be able to access that. So you might want to do something like this, where you say route group middleware, and maybe you have some kind of admin middleware that you use. Okay, so now you would wrap all of your API requests or all of the relevant API requests within that group. So in this case, this guy right here would go in there. And then I can get rid of that little example here. Okay, let's go ahead and create that.

And then I can get rid of that little example here. Okay, let's go ahead and create that. Make middleware mustBeAdmin. And if we open that up, right here, let's do something like this. We'll fetch the $user. And we'll say if we don't have a $user, like if you're not authenticated, then we immediately know you can't access this. But also, if the $user is not an admin, we'll add some kind of a little method on the User object to check that. Well, in either of those situations, you don't have permission to see the data from this.

object to check that. Well, in either of those situations, you don't have permission to see the data from this endpoint. So I will return a response of 403, unauthorized. And maybe we'll say for the message, you didn't say the magic word. Like so. Otherwise, the request is great. So we can pass it on to the next layer in the stack. All right, final step, we have the middleware, but we do need to register it in the Kernel class.

All right, final step, we have the middleware, but we do need to register it in the Kernel class. So down here, I can say, let's duplicate this admin. And this is called mustBeAdmin. Okay, now we've registered it as a route middleware, which means we can use that key anywhere here. Okay, so this should fail, right? If I give it a refresh, yeah, it fails entirely. Now also, don't forget, in this case, if you are reviewing a graph, it stands to reason that the page itself would have a middleware that would throw a 404 or redirect you somewhere else.

that the page itself would have a middleware that would throw a 404 or redirect you somewhere else. But we're just adding the middleware for the AJAX request in this case. So anyways, let's go to network, give that a refresh. I'm only reviewing XHR requests. And in this case, we get a 500. So we do have a mistake. Oh, yeah, call to undefined method isAdmin. That's because don't forget right here, we have this check here. So we'll make this very primitive, especially in situations where like, you are the only

That's because don't forget right here, we have this check here. So we'll make this very primitive, especially in situations where like, you are the only person who will be the administrator. Yeah, you can like hard code an ID or something, it's fine. You can always change it later. So let's just say, if the ID of the User is 1, then you're the administrator. That's it. Nothing else to check there. So we don't have any users. Let me quickly whip some up.

So we don't have any users. Let me quickly whip some up. We'll say factory App\User::create. Okay, it looks like this dude's gonna be our admin. We'll do another one. And anyone after that point is not. And actually, it looks like my IDs are wrong. Let's fetch. We already had some. Yeah, we did.

But if we were to come back, and let's just simulate this off login using ID, we'll simulate that that person is signed in, then they do have access. So they can properly fetch the data. All right, that'll do it for this lesson.