Open Xinkai opened 7 months ago
apollo-compiler is a library: users write code against its public API. To make upgrading painless we like to avoid breaking changes to public API where possible, or batch them so breaking upgrades are infrequent. So there’s always a tension between making the public API more powerful to enable more use cases, and not exposing too many internal details so that we can evolve them (for example) without breaking changes.
Currently you can iterate a DiagnosticList
and convert each diagnostic either to pretty formatting for CLI-like output, or to JSON as found in the errors
field of a GraphQL response.
Additionally, CliReport
can do pretty formatting for your custom errors or diagnostics.
Could you say more about what you’re trying to do, and what’s missing for you in the current API?
Thanks for the quick response!
I am exploring the idea where an LLM reads in GQL schema as a prompt, and writes out a query/mutation to fulfill users' requests.
This ticket is about dealing with LLM hallucination. Although LLMs hallucinate from time to time, I found that the hallucinations almost always "make sense", and can be used to build a roadmap for future GQL API evolution if they can be gathered and classified.
I tried .to_json()
method on one of my test cases, and I got the following, similar to what graphql-js
gives.
GraphQLError {
message: "type `Query` does not have a field `viewer`",
locations: [
GraphQLLocation {
line: 2,
column: 5,
},
],
path: [],
extensions: {},
}
What I would rather have is something like: { kind: UndefinedField, type: Query, field: viewer }
. A kind
that clearly signals this is a hallucination I care about.
I would be totally fine with building a regex based solution around the current implementation if there is some guarentee on the error message text format. Is there? I didn't find it here
Currently, I am using such a regex based solution with a unit test to prevent future breakage. So it's not a really deal breaker for me.
But it might be for some other use cases in the future. That's why I brought this up hoping to sand off rough edges before 1.0 finally drops.
Description
I am trying to build a custom GraphQL validation tool using
apollo-compiler
v1.x beta.I like the Apollo implementation's soundness thanks to the tight Rust type system.
However, the type system is restrictive for my use case, that is I can't programmatically walk over
WithErrors
and read its underlying data. It only outputs a very nicely formatted text.Is
apollo-compiler
supposed to be a library or an end-user facing application? If the Apollo team intends to build it as a library, I think it's best to fully expose the data structure ofWithErrors
andDiagnosticList
.The user-friendly error reporting can be moved to an end-user facing application, or via a separate API.
Version:
apollo-compiler = { version = "1.0.0-beta.12" }