Environment specific configuration

I think it would be important to be able to specify a different GraphQL endpoint for development and production builds of an app. For example, for development you could have a GraphQL server running locally and make a production build that uses the schema from an external production server.

Out of current configuration methods, only the GRAPHQL_ENDPOINT environment variable supports this use case, but it doesn’t allow specifying authentication credentials, so it’s not ideal.

Throwing in some ideas so far:

• It might be possible to add something like the env option of Babel, e.g.:

  {
    "request": {
      "url": "https://localhost:8080/graphql",
      "headers": {
        "Authorization": "xxxxx"
      }
    }
    "env": {
      "production": {
        "request": {
          "url": "https://api.example.com/graphql",
          "headers": {
            "Authorization": "xxxxx"
          }
        }
      }
    }
  }
  

  However, unlike Babel, graphql-config should probably not rely on NODE_ENV (it’s used to just distinguish between non-optimized development and optimized production build of an app, not different environments like testing, staging, etc. Also graphql-config will be useful in more than just JS apps (e.g. native mobile apps) so NODE_ENV doesn’t make sense there.) Therefore this approach would probably require a new environment variable like GRAPHQL_ENV. But this method of grouping config by environment is discouraged by some recommendations like the 12-Factor App. (Because doesn’t scale well when you need more environments.)

  The approach that I personally use in my apps is to read each configuration value from a separate environment variable, so that they can be overridden for testing/staging/production environments as needed, but specify the development environment settings as defaults in the configuration file, so that the development environment can be started after checking out the project from git without any additional config.

• @schickling suggested that we could include the environment in the graphqlrc filename, for example .graphql.dev.rc. I think this would be as good as the env option, but with the same drawbacks with the lack of granularity. These approaches also kind of promote storing production settings/secrets in your code repository.

I think an ideal configuration might be something like the current .graphqlrc / package.json approach, but with a way to override the settings (including authentication) through an environment variable. Any ideas how this could work?

[jimkyndemeyer]

Regarding package.json, this comes back to non-uniformity of dev environments. Not all GraphQL projects that use js-graphql-intellij-plugin are based on Node.js. Examples I’ve seen include Ruby, PHP, Python, Scala, and native Android development in Java.

So I suggest the config file name should be tied GraphQL and not the various technologies that leverage it.

/Jim

[schickling]

I haven’t really used graphql-tools yet but I think it would be nice to make it somehow compatible with graphql-config. Would be happy to hear more ideas about this @ccoffey!