Environment specific configuration #9
Description
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-optimizeddevelopmentand optimizedproductionbuild of an app, not different environments liketesting,staging, etc. Also graphql-config will be useful in more than just JS apps (e.g. native mobile apps) soNODE_ENVdoesn't make sense there.) Therefore this approach would probably require a new environment variable likeGRAPHQL_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 theenvoption, 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?