DRAFT - Resolver Metadata

[PascalSenn]

Resolver Metadata

In our last work group meeting we were discussing the UseSelection API of the new entity framework integration.
We were also discussing the [Parent] attribute we currently use to inject the parent into a resolver.

In the UseSelection feature and also in V11 of HotChocolate we will need to add metadata to fields. This will enable the execution engine to execute queries in a very efficient way. The same metadata is used to create the lambda for the projection of UseSelection. The metadata is indicating what properties have to be selected from the queryable for a give selection set.

This issue refers often to a User type defined as follows:

public class User {
    public Guid Id {get;set;}
    public string Name {get;set;}
    public string LastName {get;set;}
}

type User {
  id: Uuid
  name: String
  lastName: String
  """
  name + lastname
  """
  displayName: String
}

{
  "id": "a81f59f6-d8d6-467d-aa12-f49925265660",
  "name": "Marie",
  "lastName": "Curie",
  "displayName": "Marie Curie"
}

Terminology

Word	Meaning	Example
Property	The Property of the .Net Type	user.Name
Field	The field of the Object Type	{ displayName }

Example of UseSelection

Query	Selection
{ name }	x => new User() {Name = x.Name }
{ name lastName }	x => new User() {Name = x.Name ,LastName = x.LastName }
{ displayName lastName }	x => new User() {Name = x.Name ,LastName = x.LastName }
{ displayName }	x => new User() {Name = x.Name ,LastName = x.LastName }

Explanation:

The execution engine knows that when the field name is selected, then the property Name of the .Net Type needs to be selected. The same holds for lastName. As soon as displayName is selected, which is a composition of name concatenated with last name, both properties need to be selected.

Resolver Data

In the work group meeting we were focused on how we annotate resolvers with the metadata. It makes sense to first define what metadata we need for the execution and then define annotation interfaces.

A short overview of different types of metadata and their semantics is shown below:

MetaData	Description
GlobalState	Indicates consumption of a value of the global state
SetGlobalState	Indicates manipulation of a value of the global state
LocalState	Indicates consumption of a value of the local state
SetLocalState	Indicates manipulation of a value of the local state
ScopedState	Indicates consumption of a value of the scoped state
SetScopedState	Indicates manipulation of a value of the scoped state
Entity	Indicates consumption of a member of the entity
Field	Indicates consumption of a field of the current type
Argument	Indicates consumption of an argument
IsArgument	Indicates the equality of an argument of the parent field and the current resolver
Service	Indicates consumption of a service
Ressource	Indicates consumption of a resource

Global/Local/Scoped State

Resolver of fields can manipulate and consume state that is stored on the ResolverContext.
The implications of a consumption or manipulation of state on the execution, differ by the type of state.

Entity

The entity metadata, represents a dependency on a property of an entity. In case of a ObjectType<TType> the entity would be an .Net Object of the type TType.
In case of a stichted type, the Entity may be a collection of KeyValuePairs.

Field

Field indicates that the current resolver has a dependency on another field. In case of the execution engine this would mean that this field has to be resolved before the current resolver.

Argument

A resolver can consume arguments

IsArgument

A resolver can return the same values as an already provided argument. In the following case the field id would not need to be resolved. The field is already known because of the argument input.id.

{
  getUser(input: { id: "a81f59f6-d8d6-467d-aa12-f49925265660" }) {
    id
    name
  }
}

Service / Ressource

A resolver may have a dependency on a service. e.g. in the resolver of the field getUsers the User repository may be needed
The service may belong to a resource

{
  getUsers {
    id
    name
  }
}

Entity and Field

Entity and Field may seem equal. This is not the case.
An entity may have more information than the information represented by fields.
When we reduce the User type like the following this becomes clear:

type User {
  id: Uuid
  """
  name + lastname
  """
  displayName: String
}

The field DisplayName does not exists on the entity (in this case the .net type User), but has
dependencies on two properties of the entity.

The Problem with IResolverContext and [Parent] TParent

IResolverContext

As soon as a resovler has a dependency on IResolverContext all metadata of the resolver is gone.
The table below shows the possible metadata cause by a dependency on IResolverContext

Context Member	Possible MetaData
resolverContext.Argument	{Argument}
resolverContext.ContextData	{GlobalState, SetGlobalState}
resolverContext.LocalContextData	{LocalState, SetLocalState}
resolverContext.ScopedContextData	{ScopedState, SetScopedState}
resolverContext.Parent<T>()	{Entity* }
resolverContext.Service<T>()	{Ressource, Service}
resolverContext.Source	{Field}

[Parent] TParent

A dependency on [Parent] TParent causes a dependency of all properties of the parent entity.

Meta Data Annotation

Resolver metadata can only work when there is a way to provide the necessary information in all cases. All cases need to have way to annotate all the metadata defined under Resolver Data

Cases

PCF1 - Pure Code First Property

public class Foo {
    public string Bar { get; set;}

}

PCF2 - Pure Code First ComputedField

public class Foo {
    public string Dependency1 { get; set;}
    public string Dependency2 { get; set;}
    public string Bar() => Dependency1 + Dependency2
}

PCF3 - Pure Code First Extension

[ExtendObjectType(Name=nameof(Foo))]
public class FooExtension {
    public string Bar([Parent]Foo foo) => foo.Bar;
}

TO_BE_CONTINUED

[michaelstaib]

This is a good summary of our discussions. I will write down a view things around this on more detail once I find some time over the weekend.