[RFC] Resolver for fields only known at runtime about graphql-go

[neelance]

Hi @motiejus, I'm happy to hear that you find my project useful.

A solution that I can offer is a fully custom resolver, so you have full control on how a certain type gets resolved and which data it returns to the GraphQL client. I'm planning to implement that soon. However you'll not be able to only partially apply it to a type, it is either fully resolved by graphql-go or fully resolved by your custom code. Imho a catchall method does not fit into a clean implementation of the GraphQL spec, since any query for it would violate the schema (according to the spec).

Suggestion: Why don't you use a field like extendedPropery(name: String!): String!?

[motiejus]

Hi Richard, thank you for a quick response; it's excellent that you are willing to implement this! Some remarks:

• Re spec violation with catchall: whenever a new field gets added at runtime, I mean to regenerate schema and pass it down to the library. So from the client perspective, it would just be a new field. Only the resolver code would be a "catchall". Can you help me understand where is the schema violation?
• I am really happy with the custom resolver, and, looking from your description, I think this is what I meant with "catchall". :) Just to be sure, it would be excellent if one could write some fields "the old way" with all fields known, and some fields with the custom resolver, in the query schema (e.g. in our StarWars example, that would be Character that might get a surname, and Starship that always stays as-is). Is that what you mean? Or do you mean a custom resolver to the whole query?
• Re extendedPropery(name: String!): String!?: we currently have this, but this is a major pain point for our customers; we want to keep self-documenting GraphQL for dynamic fields too.

[motiejus]

Hi again,

Since you proposed to implement this possibility, I thought it would be a good idea to express a way how I could use it, so you can reason about developer APIs more easily.

Inspired by your graphql meta-spec, I created an example repository to express and use a GraphQL schema in Thrift. I am sure you will find the thrift schema familiar.

Currently the example is using graphql-go/graphql, because it is possible to construct the GraphQL types and resolvers at runtime.

It would be cool to have a similar ability with your library.

Edit 2017-03-15: I had to remove the example repository, but, once you get to this task, I am happy to talk to you 1:1 and explain the approach.

[hsyed]

@neelance very interested in this feature. Any ETA ? Is there somewhere I could help ?

[hsyed]

I have had a look through the code.

Would supporting map[string]interface{} as a resolver be a clean solution ? One limitation though is that to pass state down the resolver chain closure functions would would be required for the fields or using the context somehow.

Alternatively, The following contract might be a good compromise ?

type CustomResolver interface {
	__ResolvesField__(ctx context.Context, name string) bool
	__Resolve__(ctx context.Context, name string, args map[string]interface{}) (interface{}, error)
}

[wangyuheng]

I do not see this in the roadmap. Any progress or plan?

[doucheng]

Any progress or plan?

[pavelnikolov]

There are no plans to add fields at runtime at this point. I'm closing this issue due to inactivity.