Trouble using GraphiQL (gq -i) - schema missing?

[danbim]

Hi there!

I have some trouble using my graphql-kotlin server with GraphiQL (https://github.com/graphql/graphiql). While it seems to work nicely on the cmd line (e.g. using gq --introspect http://localhost:8080/graphql), it fails in interactive mode (gq -i http://localhost:8080/graphql), stating TypeError: Preflight response is not successful.

Looking at the outputs of gq --introspect ... vs. curl http://localhost:8080/sdl I can see that for the former misses the schema block:

schema {
  query: Query
  mutation: Mutation
}

I'm rebuilding a simple app I've had previously built in Scala/Calibre. In this implementation the gq --introspect response also contains the schema block, so I'm suspecting a bug here.

https://graphql.org/learn/schema/#the-query-and-mutation-types doesn't explicitly state that schema is required but it looks like implicitly it is (as it is the entry point for any client).

Would be great if you could help :)

[smyrick]

It looks like you are using this CLI tool: https://github.com/hasura/graphqurl

I am a little confused as to what the issue is. The endpoint this library provides, /sdl, has the schema block so it should be valid. However you probably want to get schema information from the introspection query as /sdl is not part of the GraphQL spec and is just there for convenience sake

Is there an issue making an introspection query with that CLI tool? Do you know the query it runs when executing gq --introspect http://localhost:8080/graphql?

[dariuszkuc]

Just a side note

schema {
  query: Query
  mutation: Mutation
}

the above is a default schema definition that generally can be omitted (i.e. if omitted GraphQL servers should default to the above). When generating SDL we opted to explicitly print out the whole schema (see link).

[smyrick]

@danbim Is your issue with the schema generator or the introspection library you are using?

/graphql is not expected to expose the SDL, it should be used for GraphQL HTTP requests only and the convenience endpoint we provide, /sdl, does have the schema block but again that is probably not the best way to get the schema

[danbim]

It looks like you are using this CLI tool: https://github.com/hasura/graphqurl

I am a little confused as to what the issue is. The endpoint this library provides, /sdl, has the schema block so it should be valid. However you probably want to get schema information from the introspection query as /sdl is not part of the GraphQL spec and is just there for convenience sake

Is there an issue making an introspection query with that CLI tool? Do you know the query it runs when executing gq --introspect http://localhost:8080/graphql?

Sorry for my late response, I only got back to this topic now. It's actually this tool I'm using: https://github.com/graphql/graphiql which seems related / a continuation of the one you found.

It seems I myself got confused by the graphical frontend of the tool which you can start using gq -i http://localhost:8080/api/graphql. The error message seems to occur when the browser makes a preflight request (see e.g. https://dev.to/effingkay/cors-preflighted-requests--options-method-3024). I can in the logs that HTTP OPTIONS is in fact not responded to:

2020-05-05 06:09:01.484 DEBUG 26081 --- [ctor-http-nio-8] o.s.w.s.adapter.HttpWebHandlerAdapter    : [7708e217-7] HTTP OPTIONS "/api/graphql"
2020-05-05 06:09:01.499 DEBUG 26081 --- [atcher-worker-1] org.springframework.web.HttpLogging      : [7708e217-7] Resolved [ResponseStatusException: 404 NOT_FOUND "No matching handler"] for HTTP OPTIONS /api/graphql
2020-05-05 06:09:01.511 DEBUG 26081 --- [atcher-worker-1] o.s.http.codec.json.Jackson2JsonEncoder  : [7708e217-7] Encoding [{timestamp=Tue May 05 06:09:01 CEST 2020, path=/api/graphql, status=404, error=Not Found, message=No (truncated)...]
2020-05-05 06:09:01.532 DEBUG 26081 --- [ctor-http-nio-8] o.s.w.s.adapter.HttpWebHandlerAdapter    : [7708e217-7] Completed 404 NOT_FOUND

[Btw. yes, /api/graphql is correct in this listing here, I previously had simplified my queries in the original question.]

In fact, both --introspect and regular queries work fine when I run them from the shell so I don't really have a problem. Just an inconvenience for users of GraphiQL. I don't depend on its usage but maybe its interesting for you to support it as it's really a great way to interactively discover APIs.

Just a side note

schema {
  query: Query
  mutation: Mutation
}

the above is a default schema definition that generally can be omitted (i.e. if omitted GraphQL servers should default to the above). When generating SDL we opted to explicitly print out the whole schema (see link).

Thanks for the clarification, I wasn't aware of it being optional.

[smyrick]

We have included the GraphQL Playground by default at /playground as it provides additional features like multiple tabs and the ability to define request headers. This should be the same exact experience as GraphiQL

However, we will keep an eye on the project as they are going to be merging together. If there is some specific bug that is not unique to your use case that we can fix in graphql-kotlin-spring-server let us know.

[danbim]

Thanks @smyrick ! I've just found out that allowing cross-origin requests as described in #398 results in GraphiQL working smoothly. So IMO it's actually a user experience issue fails to point the user to cross-origin policies.