Open etareduction opened 1 year ago
Is this meant to be able to get the schema from a web server that requires authentication or authorization? if that the case, then I would rather not add such feature to the config since it will encourage people to store their credentials in the config files and commit them to source.
If you need something like this, I would suggest to use a HTTP client like Postman to the get the schema using the introspection query, then save the result to local file schema.json
and reference that from the Snowflaqe config:
{
"schema": "./path/to/schema.json"
}
if this is too much work and you require refreshing the schema a lot, I could consider using a environment variable such as
SNOWFLAQE_INTROSPECTION_HEADERS=x-auth-token: test; x-custom-flag: test
That will be used when requesting the GraphQL schema
@Zaid-Ajaj Yes, i need this to authenticate introspection query. Environment variables would be better, but we can do both like in this example (from TS graphql-codegen):
overwrite: true
generates:
graphql/schema.graphql:
schema:
- ${GRAPHQL_URI}:
headers:
x-auth-token: ${AUTH_TOKEN}
So basically interpolating environment variables in config. I think this allows more extensibility and reuse of pre-existing environment variables in a project.
It also would be great to read .env
file for development environment before parsing the config. Might use dotnet-env for example.
So basically interpolating environment variables in config. I think this allows more extensibility and reuse of pre-existing environment variables in a project.
I feel like this is a bit overkill for Snowflaqe, I would like to keep the config simple
I feel like since the config already supports getting a schema from a file which is the result of the introspection query, you can easily download a fresh authenticated schema using curl
cat introspection.gql
| curl -H "Content-Type: application/json"
-H "Authorization: Bearer $AUTH_TOKEN"
-X POST --data-binary @- https://example.io/api/graphql
> schema.json
Does this not work for your use case?
Yeah that's what i do now but it feels less straightforward than it needs to be. I have to keep this introspection.gql file around in my projects, and also i have like 4 schemas atm that i need to regularly update (this way basically manually).
My setup includes MSBuild directives that run Snowflaqe from multiple configs before build. And it seems way too hard for me to embed those manual introspection queries in the process (having troubles with the file system access from MSBuild command directives).
Alright, I see. Then I am okay adding the SNOWFLAQE_INTROSPECTION_HEADERS
support with the .env
file. Happy to accept PR for this as always 🙏
So something like that would be possible