Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serialize schema without directive applications #807

Open
goto-bus-stop opened this issue Jan 16, 2024 · 2 comments
Open

Serialize schema without directive applications #807

goto-bus-stop opened this issue Jan 16, 2024 · 2 comments

Comments

@goto-bus-stop
Copy link
Member

goto-bus-stop commented Jan 16, 2024

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.

@SimonSapin
Copy link
Contributor

Given the context schema.serialize().without_directives_except_deprecated_and_specified_by().to_string() sounds reasonable.

@goto-bus-stop
Copy link
Member Author

goto-bus-stop commented Jan 19, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants