You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To match the graphql-js implementation in printSchema, it may be useful to have an option in .serialize() to omit non-semantic directives from the output. This would represent the schema in ~the same(?) way as introspection.
The main use in my eyes is for comparative testing of graphql-js based tools vs. rust-based tools, but maybe there are other reasons to do this as well.
For now we are doing this in the apollo-rs based tools, but we should decide if that is going to be the final situation or if we want to move it into apollo-rs.
The text was updated successfully, but these errors were encountered:
This is really only one of the things that would be required for compatibility ... the reason why directive applications are omitted is that graphql-js parses to an internal Schema representation that is basically totally unrelated to SDL, and printSchema only knows about this internal Schema representation. The internal Schema representation does not have any directives at all.
But graphql-js also parses all GraphQL values to JS values for use in the internal representation, which can cause differences in how values are serialized. When parsing default values for fields or arguments to JS values, it silently ignores invalid values (as validation is not specified for default values). In theory, parsing GraphQL values can be done by arbitrary JS code for custom scalars, so that's not something we can ever match exactly.
I don't think we should have the coercion behaviour that graphql-js has, so maybe we also shouldn't have this directives option unless there is another use case for it.
To match the
graphql-js
implementation inprintSchema
, it may be useful to have an option in.serialize()
to omit non-semantic directives from the output. This would represent the schema in ~the same(?) way as introspection.The main use in my eyes is for comparative testing of graphql-js based tools vs. rust-based tools, but maybe there are other reasons to do this as well.
For now we are doing this in the apollo-rs based tools, but we should decide if that is going to be the final situation or if we want to move it into apollo-rs.
The text was updated successfully, but these errors were encountered: