Environment specific configuration

[fson]

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?

[schickling]

Thanks for your great input @fson!

I'd like to loop in @jimkyndemeyer (the author of js-graphql-intellij-plugin) as he made some very good points why not to use a package.json approach. @jimkyndemeyer what are your thoughts on this?

[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]

Any update on this @fson? :)

[ccoffey]

The issue I have is related! When my tests run in CI graphql-config throws an error because it cannot reach my graphql production endpoints.

However, my plan is to use something like graphql-tools so that I can completely mock my graphql server during CI test runs.

Unfortunately graphql-config does not currently support this use case as there is no way to configure it not to run dependent on environment.

[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!

[schickling]

Closing this in favour of #16