Tweak the Axios Base URL for Best Dev Experience — Transcript

Transcript of the free Vue.js lesson Tweak the Axios Base URL for Best Dev Experiencewatch the video lesson.

In this lesson, I want to spend just a couple minutes optimizing our Axios base URL to provide the best developer experience. What do I mean by that? Well, here I have the Laravel course backend project open. And just like we did in an earlier video, let me run php artisan route list so that we can see all the available routes for our backend.

Okay. So you'll notice as we go through here, you can ignore all these underscore ignition things. They don't apply necessarily to our app. However, all of these other endpoints all begin with API.

So if we want to work with our links that we're going to create a little later on, we're going to be looking for links under the API prefix here. Same thing for login, logout, and all these other things. The only link that we're concerned with that does not start with the API prefix is the sanctum-csrf-cookie endpoint. With that in mind, let's make some updates to the base URL in the Axios plugin that we created in the last lesson.

So now instead of just saying localhost without any path at all for our base URL, now I want to add slash API to it. This means that whenever we use Axios now throughout the rest of our project, the slash API prefix on the path will always be available. So we can just save ourselves a few letters of typing and we can remove API throughout the code base. So slash API slash register becomes just slash register.

Nice. Now to make an exception for this sanctum, Request here because remember it doesn't start with slash API What we can do is we can add some options as the second parameter to this function call And we're looking to set the base URL This time to just local host without the API in the path Excellent. config file. And in there, you can see this runtime config variable already defined for you.

It's defined as app URL and the value of localhost. So this is like an app-wide configuration where we can kind of configure the URL for our REST API in a single spot. and really at this configuration kind of level. And this could also be overrided by an environment variable as well.

So let's use this declaration of our app URL in order to define our base URL in Axios. All right, so in Nuxt, in order to access that config that we just looked at, we can say const config equals use runtime config. Now this is a reference not to the entire configuration object here to define next, but rather to this configuration option here. All right.

So now we can say here, instead of hard coding local host, let me add back ticks so I can interpolate this value. appurl. Now this public is important because it lets Nuxt know that it can expose this app URL to the client-side JavaScript bundle, which is what we want because after all, we're building an SPA, right? We're not doing any of these server-side rendering.

So that's why we've nested that app URL under public. Great. Now we can just replace this base URL right down here with the exact same variable. Awesome.

So I actually really like how this turned out. Now I don't have to worry about prefixing any of my calls throughout the code base with slash API, like over in register. And I've consolidated all of my different uses of the app URL from the config to this single file, which turned out really nice. In this lesson, I want to spend just a couple minutes optimizing our Axios base URL to provide the best developer experience.

What do I mean by that? Well, here I have the Laravel course backend project open. And just like we did in an earlier video, let me run php artisan route list so that we can see all the available routes for our backend. Okay.

So you'll notice as we go through here, you can ignore all these underscore ignition things. They don't apply necessarily to our app. However, all of these other endpoints all begin with API. So if we want to work with our links that we're going to create a little later on, we're going to be looking for links under the API prefix here.

Same thing for login, logout, and all these other things. The only link that we're concerned with that does not start with the API prefix is the sanctum-csrf-cookie endpoint. With that in mind, let's make some updates to the base URL in the Axios plugin that we created in the last lesson. So now instead of just saying localhost without any path at all for our base URL, now I want to add slash API to it.

This means that whenever we use Axios now throughout the rest of our project, the slash API prefix on the path will always be available. So we can just save ourselves a few letters of typing and we can remove API throughout the code base. So slash API slash register becomes just slash register. Nice.

Now to make an exception for this sanctum, Request here because remember it doesn't start with slash API What we can do is we can add some options as the second parameter to this function call And we're looking to set the base URL This time to just local host without the API in the path Excellent. config file. And in there, you can see this runtime config variable already defined for you. It's defined as app URL and the value of localhost.

So this is like an app-wide configuration where we can kind of configure the URL for our REST API in a single spot. and really at this configuration kind of level. And this could also be overrided by an environment variable as well. So let's use this declaration of our app URL in order to define our base URL in Axios.

All right, so in Nuxt, in order to access that config that we just looked at, we can say const config equals use runtime config. Now this is a reference not to the entire configuration object here to define next, but rather to this configuration option here. All right. So now we can say here, instead of hard coding local host, let me add back ticks so I can interpolate this value.

appurl. Now this public is important because it lets Nuxt know that it can expose this app URL to the client-side JavaScript bundle, which is what we want because after all, we're building an SPA, right? We're not doing any of these server-side rendering. So that's why we've nested that app URL under public.

Great. Now we can just replace this base URL right down here with the exact same variable. Awesome. So I actually really like how this turned out.

Now I don't have to worry about prefixing any of my calls throughout the code base with slash API, like over in register. And I've consolidated all of my different uses of the app URL from the config to this single file, which turned out really nice.