-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Support for defining metadata on graphql types #200
Comments
I think it's a interesting idea. Especially now that schema definition language (IDL) supports directives as well. This information is not exposed to a client via introspection API and, at the moment, only part of the AST. In sangria (scala implementation), for instance, there is a concept of I find that it can beneficial to expose this application-specific meta-information to a client via introspection API. Maybe it can be exposed in a form of directives? For example a I think it would be helpful if you could list a few use-cases that demonstrate how client can benefit from using this meta-information exposed via introspection API. |
Yes I can. First of all I think it is important to see that the 'client' is much more than client-side javascript that executes queries against a HTTP GraphQL endpoint (as you usually encounter it). It has been stated that GraphQL is ideal in a microservices environment. And it is. In these kind of applications queries may cross many boundaries and use many different transports. So you can have multiple clients (and publishers) in one execution chain. Metadata can be used here for infrastructure support and configuration settings, for example. In my own use case for vertx-graphql-schema-proxy and vertx-graphql-service-discovery I want to use it for marshalling settings and to determine the point from which a query is no longer allowed to execute on the proxy client, but should be deferred to the backend. |
Its not only these more environment-specific metadata that could be relevant, but you could also use it to add much more descriptive information on the type definition itself. Think of a category, list of keywords, access modifiers, RDF descriptors, documentation links, related types, localization data, etc. |
Oh. Almost forgot to mention. The |
See also the discussion on GraphQL Java project for adding metadata. I added additional use cases: graphql-java/graphql-java#183 and my comment here #163 (comment) @leebyron I would be quite interested in your views on this topic. |
I believe this is essentially a dupe of #300, which has more discussion, and as such should be closed out. |
It would be nice if the specification defined a standard way to define metadata in a schema definition for individual types, interfaces, fields, etc. This would not be query metadata, like you have with directives, but e.g. server implementation specific metadata, or whatever an implementer needs to model additional logic on top of a schema. In other words a general metadata extension mechanism.
I described this in more detail and with examples on the
graphql-java
project in this issue: graphql-java/graphql-java#183Maybe the metadata mechanism could be implemented using an additional introspection type
__METADATA
or something similar.WDYT?
The text was updated successfully, but these errors were encountered: