Skip to Content

Your first WunderGraph Application - Deploying to Production

We're almost done with the first iteration of our application. What's left is deploying it to production, by which we mean deploying our API to the Edge.

You might have noticed that the command to initialize a new project also created a github workflow underneath .github. We can make use of this workflow to deploy our application using continuous deployment.

To prepare the deployment, we first have to create a Namespace using the WunderGraph Console. A Namespace is a container to group objects like APIs, Users, etc. together.

Once our first Namespace is created, we automatically get a primary Environment. An Environment is another important WunderGraph concept. Having different environments, like e.g. production or staging allows you to promote APIs from development to staging, etc...

Finally, we have to create our first WunderGraph API. After creating an API using the WunderGraph Console, we're able to deploy it using continuous deployment.

We wanted to make the onboarding as simple as possible. For that reason, the WunderGraph Console will show an interactive step-by-step tutorial to get up and running until the essential components are created.

Creating your account#

At first, head over to the Console and Login/Register. Currently, we offer GitHub and Google as Authentication Providers. If that's an issue for you, please let us know.

Once you're registered / logged into the Console, please follow the interactive guide and create a Namespace, an API Access Token and an API.

Configuring your GitHub repository#

Please now create a GitHub repository. Naming doesn't matter, it can be private or public.

Setting up the deployment Secret#

Once the repository is created, we have to set up a deployment secret. On the root of the repository, click on Settings, then Secrets and New repository secret. Enter a secret with the following name.

WUNDERGRAPH_TOKEN

If you haven't already created a Secret, head over to the WunderGraph Console and click on Create new AccessToken. Paste the Token into the Value field in the GitHub secret creation form and click "add secret".

Your repository is now all set to deploy your app to production.

Configuring the deployment target#

So far, we've prepared the deployment pipeline. What's missing is that we set up the deployment target of our API. That is, we need to associate our configuration with the environment and API, we've created through the Console.

To do so, create a second AccessToken using the same as above so that you can generate the deployment configuration. It's a good practice to give both tokens an easy to understand name so that you can distinguish them easily and delete them later if required. E.g. "local" for your local machine and "deployment" for the deployment pipeline.

You only have to set up your local environment with an AccessToken once.

Add the AccessToken to your local Path. It's best to add it to your bash_profile or zshrc file.

WUNDERGRAPH_TOKEN=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Once your environment is properly configured, make sure the current terminal can read it, restart the code generator. We're using the Code Generator to generate stubs for all your environments and APIs. This way, we can give you typesafe configurations all the way.

Once the Code-Generator ran, have a look at this generated file:

.wundergraph/generated/namespaces.ts

It should show an overview of all your Namespaces, Environments and APIs.

Configuring the deployment#

Let's now use the generated stubs to configure the deployment of the API. This configuration happens in the wundergraph.config.ts, using the configureWunderGraph function. Add the property deployment and configure it using the generated namespace stubs, similar to this:

deployment: {
name: "main",
environment: namespaces.wundergraph.environments["staging-wundergraph.wundergraph.dev"],
api: namespaces.wundergraph.apis.starter,
}

In our case, we're giving this deployment the name main. Our namespace is named wundergraph. As environment, we're choosing staging-wundergraph. The API we'd like to deploy to is named starter.

Deployment name#

The name property of the deployment is simply the first path element of the resulting URL after the name of the API. It allows you to publish multiple versions of an API to the same environment. This can be useful, e.g. if you'd like to publish an API for every PR you open. In this scenario, you could use the commit hash as the deployment name.

Environment#

The environment is the target environment to which you want to deploy the API. Environments can differ in capacity, redundancy, high availability, etc... One common scenario would be to have a development and staging environment in one or two regions. In addition to that, you'd usually have a production environment and at least 3 or more regions to ensure a highly available service.

API#

The api property matches your configuration with the API you've previously configured in the Console.

The final step, the actual deployment#

Once everything is configured, we're ready for deployment. Commit everything to the main branch and push your changes. The GitHub workflow will kick off and deploy the API automatically.

If you like, you can try to curl your application on the Edge. Your request should look similar to this one, just with another subdomain.

curl https://staging-wundergraph.wundergraph.dev/starter/main/operations/JspUsers

Deploying the NextJS Application#

You can use any service capable of hosting a NextJS application. Here's a list of services that make deploying NextJS applications easy:

Configuring CORS#

If you deploy the NextJS application, you'll run into CORS issues because the web application lives on a different domain than the API.

A small change to the configuration will fix this:

configureWunderGraphApplication({
...
cors: {
...cors.allowAll,
allowedOrigins: process.env.NODE_ENV === "production" ?
[
"https://nextjs-starter.vercel.app"
] :
[
"http://localhost:3000"
]
},
...
});

If we're in development, we want to allow localhost:3000. In production, we want to configure the actual domain of your NextJS application. In this example, we're using Vercel, so we have to allow the origin https://nextjs-starter.vercel.app.

Commit and push your changes to apply them to production.

As we're using continuous deployment for both the web application and the API configuration, from now on they are in sync as we're always deploying them together.

If you have any questions, please meet us on Discord


Product

Subscribe to our newsletter!

Stay informed when great things happen! Get the latest news about APIs, GraphQL and more straight into your mailbox.

© 2021 WunderGraph