Real-time with Nuxt and Laravel
This episode is for members only

Sign up to access "Real-time with Nuxt and Laravel" right now.

Get started
Already a member? Sign in to continue
Playing
06. Moving Nuxt config to .env

Episodes

0%
Your progress
  • Total: 1h 2m
  • Played: 0m
  • Remaining: 1h 2m
Join or sign in to track your progress

Transcript

00:00
When it comes to deploying your app or moving between different environments, you don't want to have stuff like the key and the host hanging around hard-coded within your plugin. If you're new to Nuxt, let me take you through how we define these environment files and then reference them
00:15
within our runtime config. Okay, so within our app, we're going to go over to the root directory and we're going to create our .env file. Much like Laravel in here, we can define any of these key value pairs. So let's start with the reverb key and the reverb host. We'll leave it at that and I'll let you change over any of the others that you need to. So over in our plugin, this
00:37
is what we want to replace and the host as well. So let's go ahead and paste in the key here and let's go ahead and grab the host here and paste this in as well. What we can now do is we can go over to our Nuxt config file and we can define out some runtime config. So let's go ahead and create out a runtime config option in here and let's go ahead and set these as public. So we have
01:01
public or just private that just hang around in the root. So we're going to go ahead and create out this public object. We are going to say reverb key. You can call these whatever you want. So you could use reverb key, that kind of formatting if you wanted to, but I'm just going to define these as they are in the emv and then we can access process.emv and then the key that we want. So in
01:24
our case it's reverb key. We can just do that for any of the configuration options. In our case we just have the host here as well. So let's swap both of these over and let's take a look at how to reference our runtime config within our plugin. So somewhere at the top within the plugin itself, not outside of here, we want to go ahead and pull in the composable to access our runtime config.
01:47
So let's just call this config and we're going to go ahead and use the use runtime config composable within Nuxt and now we can just access any of our config values. Just to give you an example of this, let's go ahead and console log on our config and just see what we get. You can see that we get an object here with, if we just take a look at the target, we've got public and app
02:08
and public is going to contain again just all of them values that we defined. So now we can just swap over the key and host specifically in this case to config public and then reverb key and then we can do the same thing for the host and that's them within their own environment and we can change these up depending on environments. So let's go ahead and pull in the reverb host and we are done.
02:32
We can also add config with where we're fetching here. We are going to change this up later but let's go ahead and change this around as well. So let's go and take the full URL here and this is now going to live under a base URL that we want to send this request with because we're just dumping this fetch request in our component rather than creating some sort of service. This doesn't really
02:53
make sense at this point but if you are going to do this it's a good idea and good practice to get into setting the base URL and going ahead and pulling that from your config. So that is going to work in exactly the same way if we just take a look here it still works but we want to put this inside of config. Now because we're still working on the client here we want to apply this to our
03:13
public as well. So let's call this our API URL and let's go ahead and pull this from API URL under our environment file which we don't have just yet. So we can go ahead and define that in here and now that we've done that we can go ahead and access this in exactly the same way wherever we're making a request. So we can pull in the same composable so let's go ahead and call this config and we'll say
03:38
use runtime config. Let's pull that in and let's go down and pull that directly into here so config public and API URL. Okay let's try this out send a request and yeah we're all good. Like I said later we're going to be changing this over to use a specific way to send API requests down for both authenticated and non-authenticated users with a cross-site request for tree token. But for now this will do.

Episode summary

In this episode, we tackle a really important step for setting up any Nuxt app: moving your config values, like API keys and URLs, out of your code and into a .env file. This change makes it easier to manage different settings across development, staging, and production, and it helps keep sensitive info safe.

We start by creating a .env file in the root of the project and add things like REVERB_KEY, REVERB_HOST, and any other values you might need. Then, we jump over to the Nuxt config and set up the runtime config, defining which values should be public and accessible in the client. I show you how to use process.env to pull your variables into the runtime config.

Next, we update the plugin so it uses the useRuntimeConfig composable. You'll see how to access your config inside the plugin, grab those public values, and swap out any hardcoded URLs or keys. We do a quick console log to see what the config looks like and make sure everything's working.

Finally, we go through how you can use the same approach in your components, for example when you need a base API URL. We add a new variable to the .env file, use it in the runtime config, and then pull it into your fetch call. I mention that we'll refactor API requests later, but for now, this pattern is a solid starting point for managing all your environment-specific settings!

Episode discussion

No comments, yet. Be the first!