[1.0] Different Environments - Different `graphcool.yml` files?


#1

When you have different environments, eg dev and prod - and say you are running dev locally and prod on the Graphcool cloud.

What’s the approach? Do you have different graphcool.yml file, such as

  • graphcool.dev.yml
  • graphcool.prod.yml

Or is there a single file with different environments somehow declared with the YAML?

Thanks.


#2

We can use dotenv files to manage different environment variables per stage. That’s a common approach to tackle this kind of situation.


Let’s say we deploy a service to two stages, dev and prod, additionally to a local development environment.

This is our graphcool.yml:

# graphcool.yml

# the name for the service (will be part of the service's HTTP endpoint)
service: my-service

# the cluster and stage the service is deployed to
stage: ${env:GRAPHCOOL_STAGE}
cluster: ${env:GRAPHCOOL_CLUSTER}
secret: ${env:GRAPHCOOL_SECRET}

# the file path pointing to your data model
datamodel: datamodel.graphql

# seeding your service with initial data
seed:
  import: seed.graphql

Notice that we’re using environment variables for the stage, cluster and secret properties. Now we can create a separate .env file per stage, where we pass in different values.

This is how it could look like for my local cluster:

# .env.local
GRAPHCOOL_STAGE="dev"
GRAPHCOOL_CLUSTER="local"
GRAPHCOOL_ENDPOINT="localhost:60000/my-service/dev"
GRAPHCOOL_SECRET="so-secret"

This is how .env for the dev stage could look like:

# .env
GRAPHCOOL_STAGE="dev"
 # this is a fake cluster
GRAPHCOOL_CLUSTER="public-springraver-singer-12345/graphcool-eu"
GRAPHCOOL_ENDPOINT="public-springraver-singer-12345/my-service/dev"
GRAPHCOOL_SECRET="so-secret"

And this could be my .env.prod:

# .env.prod
GRAPHCOOL_STAGE="prod"
# here, I chose the same cluster as for `dev`, but that's not required
GRAPHCOOL_CLUSTER="public-springraver-singer-12345/graphcool-eu"
GRAPHCOOL_ENDPOINT="public-springraver-singer-12345/graphcool-eu/my-service/prod"
GRAPHCOOL_SECRET="very-very-secret-secret"

You can then pass in the correct .env file when deploying like so:

graphcool deploy --env-file .env # or --env-file .env.prod

#3

Perfect - thanks @nilan


#4

Thanks for the steps @nilan!! however i’m getting the following error when trying to run graphcool deploy -e .env.prod

image


#5

Choosing the cluster from --interactive selector added a duplicate cluster key on my graphcool.yml file removing that and adding it to the .env.prod resolved the issue! :smiley:


#6

@ragzor what’s your graphcool -v? Please provide a bug report here, thanks :raised_hands:


#7

done! :slight_smile: https://github.com/graphcool/graphcool/issues/1590


#8

A bit new to the whole node-backend game, so sorry if this is a silly question. I just noted that under the FAQ of the dotenv lib, it says very explicitly to not do this:

Don’t quite see why, though?

Also, I’ve just tried converting my legacy console project to the GCF cli, and it’s seemed to work fine so far. However, there are only config files and .graphql files, so I’m not sure where to init dotenv using require('dotenv').config(). Is that done in the deploy when using the --env-file arg?

EDIT: Also, how can this be done in the GCF .graphcoolrc file? Using v 11.5. Is this only available in Prisma projects? Trying to test using code from the yaml variables example of GCF, but getting the error
A valid environment variable to satisfy the declaration 'env:GREETING' could not be found. and
Trying to populate non string value into a string for variable ${env:GREETING}. Please make sure the value of the property is a string.


#9

It does not seem that dotenv is supported in the Graphcool Framework at the moment (see this feature request), so ended up resorting to local yaml variables for now as outlined in this forum post. This causes the vars to be committed to git, so I’m hoping that feature request will be a reality fairly soon :slight_smile: