Graphback: `printSchemaHandler` still uses GraphbackRuntime

[craicoverflow]

printSchemaHandler from graphql-serve needs to be updated to use the new runtime API, then we can remove GraphbackRuntime.

When GraphbackRuntime is removed, LayeredRuntimeResolverCreator and any related unused files should be removed too.

[craicoverflow]

graphql-serve can dynamically load Graphback plugins from the .graphqlrc file, whereas our new API uses code-loaded plugins.

These approaches are still compatible, however I know that graphback-datasync plugin will not work loaded from a config file because Graphback rewrites graphback prefixed plugins to graphback-codegen-x.

All we need to do is remove codegen from the renaming in loadPlugins#L10 and it should work.

[wtrocki]

Nice!

[machi1990]

graphql-serve can dynamically load Graphback plugins from the .graphqlrc file, whereas our new API uses code-loaded plugins.

These approaches are still compatible, however I know that graphback-datasync plugin will not work loaded from a config file because Graphback rewrites graphback prefixed plugins to graphback-codegen-x.

All we need to do is remove codegen from the renaming in loadPlugins#L10 and it should work.

If we drop codegen from the renaming, it will mean having to change configurations like this https://github.com/aerogear/OpenVolunteerPlatform/blob/master/platform/server/.graphqlrc.yml#L17 to add the codegen?

[craicoverflow]

If we drop codegen from the renaming, it will mean having to change configurations like this aerogear/OpenVolunteerPlatform:platform/server/.graphqlrc.yml@master#L17 to add the codegen?

Yes it does mean this.

plugins:
  graphback-codegen-schema:
    format: graphql
    outputPath: ./src/schema

Unless we were to deprecated @graphback/codegen-schema and republish it as @graphback/schema, since technically codegen is optional and not so important anymore, so it might not make sense to call it that.

[craicoverflow]

Also - we rename @graphback scoped packages as hack of sorts because YAML does not let you write @graphback/codegen-schema as a key. This hack will not work for non-graphback scoped plugins from different organisations, such as @my-cool-org/awesome-graphback-plugin.

[machi1990]

Also - we rename @graphback scoped packages as hack of sorts because YAML does not let you write @graphback/codegen-schema as a key. This hack will not work for non-graphback scoped plugins from different organisations, such as @my-cool-org/awesome-graphback-plugin.

I see now. The workaround is for users have to use the programmatic API (new runtime api) to define plugins?

[craicoverflow]

The workaround is for users have to use the programmatic API (new runtime api) to define plugins?

This will work for most scenarios but it means we can't use plugins with graphql-serve, since there is no code to programatically define plugins it needs to rely on something like graphql-config.

Unless we changed how plugins need to be defined in graphql-config to:

Of course, graphql-config files can be defined in JSON too which could fix this, but ideally we should not force people to use JSON/JS when YAML seems to be the popular choice.

[machi1990]

If we drop codegen from the renaming, it will mean having to change configurations like this aerogear/OpenVolunteerPlatform:platform/server/.graphqlrc.yml@master#L17 to add the codegen?

Yes it does mean this.

plugins:
  graphback-codegen-schema:
    format: graphql
    outputPath: ./src/schema

+1 with dropping codegen from the rename logic.

[wtrocki]