Skip to main content

Vercel

Vercel is a deployment and collaboration platform for front-end developers. It enables us to host our TaskFlow app without any configuration. Vercel can monitor our repositories and is on the lookout for commits. When one occurs, Vercel will take it on itself to build and host our application on its servers and make it publicly available.

While Vercel doesn't require us to have any sorts of configuration, we still want to ready our app before sending it into the great outdoors. First we'll want to make a few changes to our services as they currently fetch from our localhost. If Vercel is setup, our next commit will be visible online. Before committing new code, let's make our fetch production ready.

My JSON Server​

There is a neat little service that can act as our REST Server. Use the My JSON Server endpoint for your services and check whether this properly works both locally and with help of the automated deployments. Note that their service requires the repository to be public.

Environment variables​

When deploying, and thereby sharing what you made with the world, you want to make sure you don't also immediately spill all the secrets your application has been keeping. Preventing that from happening is one of the purposes of environment variables. These are variables whose value is set outside the scope of the application.

Node.js provides us with something called process.env. The process object is a global object that provides information about what is going on in our Node.js application. Next.js comes with built-in support for environment variables. More about that here.

First, let's create a local environment file with a variable. Notice how it's prefixed with NEXT_PUBLIC_ as Next.js lets us expose the variable to the browser this way.

.env.local
NEXT_PUBLIC_DB_HOST = some-value

Now we can access this through process.env.NEXT_PUBLIC_DB_HOST and have a working fetch for both our local and remote environments. Make sure to add the .env.local to the .gitignore to keep it out of harm's way!

Implementations​

Next.js built environment variable reading using .env.local, but also features .env.development and .env.production which aren't supposed to be ignored by Git, as a helpful tool on deciding variables for different environments. They introduced this themselves because there isn't a perfect common denominator to declare these variables.

They can be added in a multitude of ways:

  • Using the command line/terminal. This can be useful when using a different tool to add environment variables through the terminal.
  • A tool like Docker. Docker has its own specified method of setting environment variables.
  • Setting them in the package.json. This might be overseen when looking for env variables.
  • Other build tools like Earthly.

Finally, in the CI/CD pipeline, these variables are set in a similar fashion, sometimes using the pipeline tools.

Some variables have typical names. Say, you want to set the literal environment, write it out like so: process.env.NODE_ENV = development. This makes it easily recognisable for other developers.

Recources 📚​