Auto-Stitching

With the current version of schema stitching we still have to do a lot of work regarding the schema SDL in order to stitch together two schemas.

In order to make this easier and less error prone we want to introduce some kind of auto-stitching.

Auto-Fetch Schema

First part of this story is that I do not want to provide the remote schema with a schema. #543

So instead of:

serviceCollection.AddRemoteQueryExecutor(b => b
    .SetSchemaName("contract")
    .SetSchema(FileResource.Open("Contract.graphql"))
    .AddScalarType<DateTimeType>());

I just want to say:

serviceCollection.AddRemoteQueryExecutor(b => b
    .SetSchemaName("contract")
    .AddScalarType<DateTimeType>());

The stitching layer shall the fetch the schema via introspection from the remote schema. I still will need to provide scalars that are not defined in the spec.

Auto-Merge Schema

The next part of this story is auto-merging a schema. The auto merge shall provide a simple root field merging. So, root fields from both schemas will be merges. In order to solve collisions we want an ISchemaMergeCollisionResolver which can be passed in.

The default collision resolver will merge like the following when the name of a type is used in both schemas:

• Input types that are completely equal (including enums) will be merged so that a single type exists in the stitched schema.

• Input types that are not 100% equal or that are output types will be prefixed with the schema name. So, the [typeName] becomes [schemaName_typeName].

Extend Types

In order to make the types more useful and provide a deep level of stitching it shall be possible to extend the types via the sdl.

extend type Foo {
  bar: Bar @schema(name: "schemaName") @delegate(path: bar.bars)
}

Builder Support

For the stitched schema we should provide a builder class that makes it easy to create the stitched layer.

StichingBuilder.New()
    .AddRemoteSchema(foo)
    .AddExtensionFromFile("Extensions.graphql")
    .AddMergeHandler(next => (context, types) => next.Invoke(types))
    .RemoveField(new FieldReference("Type", "field"))
    .RenameField("schemaName", new FieldReference("Type", "field"), "newFieldName")
    .RenameField(new FieldReference("Type", "field"), "newFieldName")
    .Merge();

[michaelstaib]

@OneCyrus we have integrated the lazy stitching functionality with 0.8.0-preview.5. Should be available any minutes. I have an example read demonstrating this. I will push that to our example repo as soon as the package is online.

[OneCyrus]

while this is perfectly fine, a code first approach for extending types would be welcome.

What do you think about adding a ObjectTypeExtension this would be basically the extension representation in csharp.

Or we could introduce a ObjectTypeExtensionBuilder this might actually be more useful. The builder lets you describe what you want to add to a schema.

sounds good. currently I’m not sure what would be the most logical way of defining it. while a builder would give the most flexibility it’s probably also very verbose and complex. i really like the otherwise simplicity of the hotchocolate API but with still very deep extension points when needed. I’m sure you’ll figure the perfect balance for this.