Zaid-Ajaj / Snowflaqe

A dotnet CLI to generate type-safe GraphQL clients for F# and Fable with automatic deserialization, static query verification and type checking
MIT License
154 stars 25 forks source link

Config options to set headers for introspection query #84

Open etareduction opened 1 year ago

etareduction commented 1 year ago

So something like that would be possible

{
    "schema": {
        "url": "https://...",
        "headers": "x-auth-token: test; x-custom-flag: test"
    }
}
Zaid-Ajaj commented 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

etareduction commented 1 year ago

@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.

Zaid-Ajaj commented 1 year ago

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?

etareduction commented 1 year ago

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).

Zaid-Ajaj commented 1 year ago

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 🙏